I have an EMU2 and have been wanting to get the readings imported into HASS for some time now.
Looking at lots of existing examples/components/whatnot I managed to make a custom component (more information/references at github location)
Hope this lets anyone else with an EMU2 get readings into HASS!
- 1-2 times at startup it did not initialize correctly (and would not update sensor values until restart).
- If the emu2 fails to initialize serial (e.g. pi not recognizing it, try different USB cables)
- If not running HASSIO (e.g. Ubuntu), make sure to have pyserial (via pip3 install pyserial)
# Example configuration.yaml entry
- platform: rainforest
5.1.19: added known fixes found by @hasbro and @danmarotta5
4.21.19: platform: emu2 -> platform: rainforest
4.23.19: fixed link to github
This is pretty awesome - thanks for sharing. I’ve been debating getting one of these but hadn’t hard the time to start from scratch - looks like you’ve done all the heavy lifting already
Question - do you have this hooked up to a Raspberry Pi where Home Assistant is running? Any other setup needed to get the device talking with the Pi?
Thanks for sharing your code. Plug and play! Works great.
Nevermind my previous question. It was dark in the network closet and I didn’t see I did have one open USB port.
I wanted to let you know that updating to version .92 breaks this custom component, even with switching around the folders/naming convention to meet the new requirements. Any chance you could update the project for the newest version of Home Assistant? Your project works great, and there is such little info on this sensor.
@hasbro, give it a try now. @BrianHanifin migrated the component to the new format and updated the readme (File structure migration) – Do note that the component was renamed from emu2 -> rainforest
@jrhorrisberger Thank you for doing the hard work making it in the first place! I just got it ready for Home Assistant 0.91 (and beyond) for selfsh reasons… then decided not to be selfish and contributed it back to your repository.
You should update the link in your original post.
Great work, and thank you for the work on this. The update does work perfectly now with .92.
I did want to add that (at least on Hass.io) that initially it did not work even after a few reboots. What I discovered was through dmesg, that the correct recognition of the device wasn’t happening at boot. By unplugging and plugging it back in while the system was up, the dmesg returned the correct profile and set it up on * /dev/ttyACM1. Also, I discovered that not all micro-usb cables are able to transfer the data, including the one that came with my unit. Both on Hass.io and on Windows, nothing would happen when I plugged it in, I tried 3 different cables and suddenly one of the worked. I hope this helps someone out in the future if they are having similar issues.
Also, the device works great with the new “utility_meter” and “statistics” platforms that are included in Home Assistant.
@hasbro Are you running batteries in your emu2? I wonder if it is related to this?
As on page 15 of the Emu-2-Tech-Guide-1.05.pdf they have the following line:
Ensure that the EMU-2™ is powered only by its AC adapter, and there are no batteries installed; power from the batteries may interfere with operation of the USB port.
I did have issues getting my laptop to recognize the emu2 with batteries when I first started playing around with it. However, it seemed to work with batteries on the pi, so I left them in. I’m going to try taking the batteries out of mine completely to see if the issue goes away.
@jrhorrisberger I took the batteries out as part of my troubleshooting. My issue was definitely the micro-usb cable. Certain cables just will not work, it is very strange, but after trying at least 4 different ones it suddenly worked. After unplugging while the system was running and then plugging it back in while the system was still running, then reboot. It has been logging reliably for several days and also survived an OS reboot (no batteries). Maybe the batteries keep the power on, and when it isn’t powered by batteries, it gives it a chance to boot while the OS is starting up and has a better chance at being recognized? Just a guess.
I installed you custom component using 0.92.1 and the device loads without error however the data isn’t instantiated … I tried and few inserts/restarts and a reboot … I can see /dev/ttyACM0 load in dmesg … when i cat /dev/ttyACM0 I can see the correct xml data stream from the EMU-2 … any ideas what I’m doing wrong ? ( running on Ubuntu 18.04 on intel NUC )
i needed to add pyserial via pip3 install pyserial … now working
@danmarotta5 – I was thinking on it today and was on the fence about it being a dependency error or some sort of string parsing issue, but you beat me to it. Glad you were able to get it working!
@danmarotta5 / @hasbro – I updated your findings to the first post (and github) to save time for others in future
Has anyone had problems with the values this is outputting being ridiculously high at times, and other times perfectly reasonable? For example it is showing “4,294,966.287 kWh”.
Looking more closely, that dip in the middle is overnight where it reads (1.22 kWh). So, maybe it is always reading that high. Is there a setting on the device I need to change? Or do I need to divide by 1,000,000 to get the correct answer?
@BrianHanifin – I’ve not seen this before. I don’t know if the EMU2 sets the Multiplier/Divisor or if this comes from the utility. I suspect the values from the XML/serial are weird? The value in HA should match the one on this screen (There is a PR on github to fix the units from kWh -> kW)
Code excerpt below.
demand = int(xmlTree.find('Demand').text, 16)
multiplier = int(xmlTree.find('Multiplier').text, 16)
divisor = int(xmlTree.find('Divisor').text, 16)
digitsRight = int(xmlTree.find('DigitsRight').text, 16)
if(divisor != 0):
self._state = round(((demand * multiplier) / divisor), digitsRight)
Oh, I had never seen that particular screen before because I hadn’t set a cost per hWh. It is currently showing -1.0¢/hr and -3.281kW. Apparently there isn’t a way to set the price the power company gives for sending my overage back to the grid 3¢, while I think they charge like 33¢ per kWh used. (I really need to get some solar batteries.)
I tried the new code. Unfortunately the component is still showing showing 4,294,964.042 kWh. But at least I can see that the device, I believe has the correct values displaying.
@BrianHanifin Did you find a solution? Thanks
Unfortunately no. I’m not really sure how to troubleshoot the problem.
@Krapstar I am experiencing the same problem and think I have some insight thanks to help from Rainforest, but I’m not smart enough to determine how it should be fixed in the script. Apparently when you have solar generation and the net demand is negative, the data is returned in hex signed 2s compliment format. The current code is converting it to decimal incorrectly.
E.g. a recent output from my system:
Straight decimal conversion is 4,294,960,461. But the correct conversion is -6,835, which after applying the divisor is -6.8kW.