Here’s how my dashboard turned out. I have a zwave power monitoring device to get home power consumption, so I can compare solar generation to house power consumption.
Overview:
Card per inverter
Here’s how my dashboard turned out. I have a zwave power monitoring device to get home power consumption, so I can compare solar generation to house power consumption.
Overview:
Card per inverter
Which zwave device is that ? I have few plug that measure , but don’t measure whole house yet, which I would want to do.
Nice dashboards Kyle. By the way, I’m not too worried that we might get firmware updates. Using our method of pulling data from the ECU-R over WiFi prevents good practice to only perform firmware updates using ethernet/cabled LAN. That is, if you keep the ECU-R unwired to your network.
Sander, I bought a P1 USB to RJ11 cable and inserted it in my smart meter. For the Netherlands there is a DSMR integration (Netbeheer Nederland) I use.
This is the zwave device I have.
Great, added them. In about 45 minutes it will be 2021 in the Netherlands! Happy new year all!
This 0.7 power consumption from house, is from template logic i assume?
if you measure line in power, you dont measure the consumption from panels to devices in house.
So then power from panels minus power to grid is consumption ?
This makes it slightly difficult to make it accurate if Power to grid is measured each minute and power from solar is measure each 5 minutes. Already spotted mismatch in that today, sum didnt add up.
@ksheumaker Added protocolsheet for the QS1 type inverters.
Nice, inverter signal seems to vary. Even an outage (but that is due to my experiments with the ECU I Guess). It’s a great way to analyze signal strengths and interference.
Home power consumption is measured by the zwave device. It’s connected to my main circuit breaker box, so it gets everything to the house.
I actually don’t have a way to measure the power to grid, so i’m using the template logic on that. Sounds like you guys are lucky and can query your meter directly, mine is on the outside of the house, and doesn’t have any user serviceable ports. It does have a zigbee logo on it though, so I might attempt to sniff that at some point in the future, but my electric company doesn’t provide any assistance or info on how to use that feature.
So you are correct, it’s not 100% accurate, but it’s close enough for me, I just wanted a good idea what my system is doing.
fully get that. I am just looking for options to measure things and was curious.
For now i have some discrepancies in what energy meter sees as delivered and what ECU says what panels produce. Sometime the power to grid is higer then what ECU reports and that is caused by measurements timing. I’ll try to have ECU more updates than once in 5 minutes and see if that makes sense to keep.
Only when i get that gap closed, that TESLA energy card would really make sense
very happy with graph per panel now btw. Need to figure again where my panels are placed, the cards are not the right layout
Enabled today the service mode for more udpates in data. In that mode the data gets refreshed every 20 seconds , so the 1 minute polling HA integration is making steady updates now. Kind of like this, i’ll let this run for few days to see if it stays usable
commands are
APS1100320053[ECU-ID]END1END = Servicemode on
APS1100320053[ECU-ID]END0END = Servicemode off
will now add the tesla power card
Ok let me know after it’s run for a few days and stays stable. Should be pretty easy to add as an option in the yaml config.
I was experimenting with domain blocking today and as is seems, blocking the domain ecu.apsema.com to prevent updates to EMA cloud has some logical but undesired effects which need some further reseach.
First signs in HA:
After a while HA cannot be reached anymore (no response on URL). I don’t know if there is a solution to this, I’ve seen unreachable entities before but HA kept on being available. Maybe there are some rules attached to how to error handle these situations and can the script adapt to handle this?
After a restart of HA, HA continues to work but with the same error message. Inverter is down because there is no more sunlight. Perhaps that is why the entities are in error? No more data is coming in from the ECU-R. If so, it might be a good idea to show the last good situation values for the daily totals and totals and set other parameters like current watts to zero. I’ll look at the situation tomorrow morning when the inverter starts to send data again. Maybe the script will then recover.
hey kevin, got some logs that kind of mess up responsiveness of HA i think (not 100% sure)
Could you have a look and see if we can handle the situation bit cleaner?
Logger: custom_components.apsystems_ecur
Source: custom_components/apsystems_ecur/APSystemsECUR.py:82
Integration: APSystems PV solar ECU-R (documentation)
First occurred: 10:19:21 AM (3 occurrences)
Last logged: 10:30:21 AM
Unexpected error fetching apsystems_ecur data: invalid literal for int() with base 16: b''
Traceback (most recent call last):
File "/srv/hass/lib/python3.7/site-packages/homeassistant/helpers/update_coordinator.py", line 144, in async_refresh
self.data = await self._async_update_data()
File "/srv/hass/lib/python3.7/site-packages/homeassistant/helpers/update_coordinator.py", line 132, in _async_update_data
return await self.update_method()
File "/home/pi/PI/.homeassistant/custom_components/apsystems_ecur/__init__.py", line 41, in async_update_data
return await ecu.async_query_ecu()
File "/home/pi/PI/.homeassistant/custom_components/apsystems_ecur/APSystemsECUR.py", line 50, in async_query_ecu
return self.query_ecu()
File "/home/pi/PI/.homeassistant/custom_components/apsystems_ecur/APSystemsECUR.py", line 70, in query_ecu
data = self.process_inverter_data()
File "/home/pi/PI/.homeassistant/custom_components/apsystems_ecur/APSystemsECUR.py", line 123, in process_inverter_data
inverter_qty = self.aps_int(data, 17)
File "/home/pi/PI/.homeassistant/custom_components/apsystems_ecur/APSystemsECUR.py", line 82, in aps_int
return int(binascii.b2a_hex(codec[(start):(start+2)]), 16)
ValueError: invalid literal for int() with base 16: b''
This morning my HA was unresponsive again, even though i did not use the service mode anymore. The above log was showing on 9:21 and at 9:20 the ‘no inverters active’ error.
Really Seems something in handling errors is making HA not reachable anymore as result. Any idea @ksheumaker?
I’m almost thinking not to try to update sensors after sunset could be useful here.
Haven’t touched the ECU-R since yesterday and fortunately HA kept on being available.
I agree things can be made more robust. I’d like to see a Max Power today added to the component, it’s one of the visual parameters on the EMA site and it would be convenient to have it also available in HA.
Edit: It’s now the end of the day, almost no daylight left and the error mentioned earlier popped up again. After some thoughts I tried again and the entities are available again. Here’s the error log:
2021-01-04 16:07:35 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn’t return minimum 16 bytes, no inverters active.
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 144, in async_refresh
self.data = await self._async_update_data()
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 132, in _async_update_data
return await self.update_method()
File “/config/custom_components/apsystems_ecur/init.py”, line 47, in async_update_data
return await ecu.async_query_ecu()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 55, in async_query_ecu
return self.query_ecu()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 65, in query_ecu
self.process_ecu_data()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 116, in process_ecu_data
raise Exception(“ECU query didn’t return minimum 16 bytes, no inverters active.”)
Exception: ECU query didn’t return minimum 16 bytes, no inverters active.
Status now is 0 watts but temperature is 4 degrees celsius and 83% signal strength (still receiving data):
i vaguely have two feelings today:
the first i can’t address/test, but will move my devices a bit to different segment to determine if it’s true or not
Weak device like in unable to handle too much Zigbee data? Zigbee signal strength is good enough on all inverters? I don’t know if the device is to blame when we push it to limits in Service Mode. What is the interval on which you receive data changes on the ECU-R?
I haven’t had an issue with HA going down, that shouldn’t happen. Even if my integration is really broken, the exceptions shouldn’t cause HA to crash. The error you are seeing about “no inverters active” is from this piece of code, which I lifted from the original example posted here. But the summary is it didn’t get data from the ECU-R.
if len(data) < 16:
raise Exception("ECU query didn't return minimum 16 bytes, no inverters active.")
The other error, indicates that it got an empty byte string b''
when trying to decode where an integer is supposed to be in the data stream.:
ValueError: invalid literal for int() with base 16: b''
I have seen the sensors go unavailable, but not since I finished my testing. I was seeing the unavailable happen when I was testing and restarting/requerying the ECU at a much more frequent rate. When they did go unavailable my ECU was no longer responding to 8899. I had to power cycle it to get it back.
I agree the device is pretty under-powered, and I wouldn’t be surprised if there are some bugs in my code. I can certainly try and be more response to not getting data in the code, and handle a few of these errors better.
I’m not 100% sure what we’d want it to do in a situation when it couldn’t get data from the ECU? I can cache the last results, and send them in again, but I’m not sure anybody wants that? I also think increasing the interval from 60 seconds to 120 might be worth doing. If you want to try that change the code in __init__.py
line 41
interval = timedelta(seconds=60)
If I lookup the MAC address of my wifi interface on the ECU-R it appears to be mfg by espressif which generally means it’s an esp8266 or esp32 which are very low power, low performance microcontrollers. I think this is just providing the wifi connection to the rest of the device, since there is generally not zigbee or ethernet provided by those controllers.
It’s an ESP07S. I’ll try to decrease the pulling frequency but it can’t be the issue, you might expect that one minute is enough to recover from processing received Zigbee data or previous request on ECU-R. Since I let the whole setup running without touching anything, this is the log of today (I think missing a beat now and then is nothing to worry about).
2021-01-04 02:46:29 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: [Errno 111] Connection refused
2021-01-04 07:32:48 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
2021-01-04 09:23:07 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: invalid literal for int() with base 16: b''
2021-01-04 11:03:28 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
2021-01-04 11:38:48 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
2021-01-04 14:53:15 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
2021-01-04 16:07:35 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
2021-01-04 16:27:54 ERROR (MainThread) [custom_components.apsystems_ecur] Unexpected error fetching apsystems_ecur data: ECU query didn't return minimum 16 bytes, no inverters active.
Would it be possible to apply the checksum to the received data? And just drop the data if the checkum ain’t matching up?