emonESP firmware development

You’ve probably already considered this, but did you;
git fetch origin
before checking out the code_split_up_cpp branch?

Paul

This worked for me from a fresh clone;

jeremy@MOONSHADE:~$ git clone https://github.com/openenergymonitor/EmonESP.git
Cloning into 'EmonESP'...
remote: Counting objects: 1015, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 1015 (delta 0), reused 0 (delta 0), pack-reused 1011
Receiving objects: 100% (1015/1015), 462.41 KiB | 0 bytes/s, done.
Resolving deltas: 100% (494/494), done.
Checking connectivity... done.
jeremy@MOONSHADE:~$ cd EmonESP/
jeremy@MOONSHADE:~/EmonESP$ git fetch origin
jeremy@MOONSHADE:~/EmonESP$ git checkout code_split_up_cpp
Branch code_split_up_cpp set up to track remote branch code_split_up_cpp from origin.
Switched to a new branch 'code_split_up_cpp'
jeremy@MOONSHADE:~/EmonESP$

or I think you can also use git pull origin code_split_up_cpp

1 Like

From a fresh clone, the available branches should already be synced from Github, and immediately available to checkout.
With existing ‘clones’, it’s necessary to refresh the branch list, to pull-in new branches before they can be checked out.

Paul

1 Like

I though only the master was fetched… clearly not :wink:

I’m no expert Jeremy - I’m slowly learning from my disasters!!

Paul

Ditto :wink: You can’t become the former without the latter

2 Likes

Thanks Paul :thumbsup:

@jeremypoulter are you running the latest code from code_split_up_cpp? How’s it working for you? I don’t have access to an ESP untill next week. I will test then. It would be good to ensure stability by running for a week or so before we decided to merge. I’m happy with (and actually quite like :blush:) the new code layout. It will make mentainability and adding new feautres much easier in the future.

Also like @chris1howell said it will make it easier to share code modules between EmonESP and OpenEVSE :slight_smile:

1 Like

Yeah, looks to be working well, have a look at the message delivery stats (code_split_up_cpp code was installed around 21:30 on the 24/08/2016) from EmonCMS;

https://emoncms.org/vis/multigraph?mid=11834

and the power stats via MQTT (via Adafruit io);

Need to test out the management side of things a bit more.

1 Like

Awesome! Interesting to see that Free Heap dropped, probably not significant. It certainly looks like it’s still working reliably. Adafruit.io is quite nice

My EMONPI module has started playing up so I’m thinking of taking the ESP route.
Is it possible in future to extend the ESP firmware to allow control of the GPIO ports? I currently have 2 ESP8266 Wemos D1 Mini’s running ESP Easy and via MQTT I control lights and 1-Wire sensors. I’d like to extend this via additional ESP Modules attached to my EMONTX’s if possible.

I think this is because I accessed the web server soon after installing the new firmware. Once it has been up for a week or so will I will reboot and see if that recovers the memory. Not that keeping memory free is actually a good thing :wink: free memory is wasted memory :wink:

Indeed, there are a lot of nice features about it, eg mobile friendly dashboards, real time updates, but it is also rather limited when compared to EmonCMS.

1 Like

FYI I rebooted the EmonESP earlier this week and there is a lot more free memory now. Interestingly there are two other points where the memory jumps up by ~200 bytes when it gets disconnected from the WiFi (I had to move the router so it was turned off fir a while).

code_split_up_cpp branch has been merged into master, tested and working great for me :slight_smile:

Actually, it was merged 8 days ago, I just forgot to post here :neutral_face: . Are you happy for me to delete the code_split_up_cpp branch?

Go for it, was only documentation that was outstanding.

I am also interested in accessing gpio to allow reading data from pin.

Take a look in this thread ESPEasy and EMONTX - it seems to work!
I’ve been using this for a few weeks now without issue

Thank you. But i think it’s easier to slightly change emonesp sketch to read from pins aswell rather than uart. Any help?

Hopefully someone else can help you with this one, I already use ESPEasy on other ESP devices reliably to control things so have no need to develop another solution. I run EMONCMS locally on the same Pi as Openhab which is detailed in the other thread.

How do you send data to emoncms through espeasy?

see first post on ESPEasy and EMONTX - it seems to work!