-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compatibility with emonpi and flexible sending of data via MQTT #12
Conversation
In EMONPI mode, a script is provided which is used to send updates to the display. This uses emonhub to send the data via RF. The advantage is that the script 'emonglcd-send.pl' can be configured to subscribe to any topic using MQTT and use those values sent directly to the display. This is useful as it avoids having to use EMONTX and 'sniff' the data off the air. EMONHUB/EMONPI can maintain the solar PV and utility readings and calculate the Kwh. Any feeds or inputs can be sent to the display for these values. This is useful if you are using emonhub for aggregation purposes, potentially using other sources (modbus reading via external power meters or reading inverter directly) rather that CT coils connected to emonpi/emontx. Any emonhub input or feed can be used to set the values on the display, and all is configurable in emonglcd-send.cfg
emonpi using MQTT
Great, thanks for this. I also liked the emonGLCD. The main issue was that it was difficult to manufacture pre-assembled at a reasonable price. Most users don't want to build up the kit. We still have kits left in stock which we're struggling to sell: https://openenergymonitor.com/sale-emonglcd-lcd-display-unit-kit/ |
Thats real shame. The unit absolutely rocks. It's a lot better in person than in the pics on the site too. I'd really really hate to see it discontinued, as it really fills a niche. Maybe there is a way to make a SMD version that would save a lot of assembly, leaving only the display to solder on ? I bought three of the things I was so impressed... |
That was the main issue that making an SMD version was going to be tricky and hard to do in a cost-effective way. Especially since a proper injection moulded enclosure would be required to give the unit proper protection to obtain CE mark. The injection moulding process was going to require a significant upfront investment. The feedback we got was the most users would prefer to use a smartphone or tablet. We may revisit it, maybe a 3D printed enclosure could work for a small batch run. |
So what I meant was the PCB could be all SMD and completed. I think I understand what you mean, to sell as a completed product requires all of the above to get CE. That's such a shame. Also, locating and loading the firmware on these devices is a huge blocker. You have tinkerers who don't have all the kit to flash an arduino, nor will to do so. But they are quite cable to solder something together... Sorry I just love the device in it's current form (apart from the hour required to solder it together ;) ) PS, if you could update the shop page to say it is now compatible with the emonpi that may help ! |
That's a good idea. So all a user has to do is to add the following to emohub.conf to send emonPi data to the emonGLCD:
And then have some sort of service to post the data to MQTT? How are you doing this? Maybe we could post a nodRED example? |
Exactly ! That's all the user has to do is add the above to the emonhub.conf. I created a service to do just that (send via MQTT) and is very configurable. It's included in the pull request for this. From the readme A companion script (emonglcd-send.pl) has been provided in this repo that reads any emonhub node/feed values and transmits them to mulitple emonglcd(s). A systemd run file has also been provided to run this at startup, simply place systemd/emonglcd.service into /lib/systemd/system and run 'systemctl enable emonglcd' I also have some nodered stuff going on to integrate with Alexa ('Alexa open bedroom blinds!') that sends via nodeRed/MQTT node to emonhub which is then transmitted to the jee node. I'll dig it out. Personally as someone who had no mqtt/node red experience until a few short months ago, the mosquitto_pub and mosquitto_sub test programs were invaluable. |
Got it, the updated emonglcd readme explains it well. I still think a nodered flow would be easier for most users. |
So I'm all for choice.
Please test it. I'll add the node-red flow to the emonGLCD repo and do another pull. I think I will add the daemons to the emonpi repo in the right places, so they are setup and ready to go. That way, a user doesn't have to use node-red and the emonGLCD should work with emonpi out of the box ? |
Thanks. NodeRED is no longer installed by default on the emonPi. But it's easy to install if required. |
I hate hi-jacking a commit thread for this, but... I do feel leaving out node-red and openhab is bad. Very bad. I read Trystan's thread on the future of development and shuddered at the thought of containers, and really think you'd do well sticking with raspian. Containers raises the complexity, barrier to entry and will reduce people like me 'discovering' and hacking on the cool stuff you make..... I get it may make your life easier as no one is changing stuff 'under your' feet. But it also means you don't evolve as quickly to new things... It may also be worth raising the spectre of why you don't use standard debian package management .. this might make updates easier and packaging easier too (after the pain of setting it up) Please keep emonpi as open as possible... The fact it's rasppi inside attracts a lot of clever folks, and those folks know raspian... :) my 2c ! And thanks again for great products! |
Thanks for your comments, it's really great to hear that you have found the emonPi and nodered useful. I personally pushed to get nodered included on the emonPi, however, it has become apparent that not many users use nodered / openhab and even fewer users apply security updates. We considered the increased attack vector of having nodered/ openhab running unknown to many users was not worth it. At the same time, we have also changed our latest emonSD image to dropping our read-only root file system, so installing NodeRED on the current emonPi is as simple as You raise a valid point about the increased complexity of containers. However, containers offer lots of positives for developers and users. I personally think that if we documented the development process and made developing using containers accessible it would bring significant benefits. We did investigate using Debian packaging but for the emonPi we require much granular lower level access. No decision has been made yet, we're still evaluating options. Thanks again for your feedback. |
This feature adds the ability of emonGLCD to work with emonpi, and for the emonGLCD to receive data via MQTT.
It allows to select any node/input variable in emonpi and send them to multiple emonGLCDs for display using MQTT (script provided to do so)
It also makes minor improvements to the codebase, for example checking RF data received length and if the RF data is for itself.
The emonGLCD is a great device and I'm saddened to hear it's discontinued. Maybe this code update will make it live again ?