Wrong readings when cloud is blocked

[Julian0021]

When the DTU has no access to the internet, every reading in an interval of exactly 3 minutes is 0. All readings in between are correct.

[Julian0021]

This does not affect actual production, just the reading is wrong.

[suaveolent]

That it interesting and reminds me of #11.

I assume you are already running the latest version?

[Julian0021]

Yes, running latest release available in HACS (and latest dtu firmware)

[suaveolent]

If you enable cloud access, do the values normalize?

Also to ensure: Are you running only the custom component or anything else in parallel which accesses the inverter?

[suaveolent]

I know @dicer is running the inverter without Internet access successfully.
Maybe he can help?

[dicer]

I'm still running the factory firmware cause update doesn't work as planned offline. I don't see your pattern though. The old firmware version is regularly dropping from the wifi and I get very sporadic readings only (same on two inverters). What is HACS btw?

[Julian0021]

If you enable cloud access, do the values normalize?

Also to ensure: Are you running only the custom component or anything else in parallel which accesses the inverter?

Yes, as soon as cloud access is reenabled the values normalize. And no, this integration is the only thing messing with the inverter

[suaveolent]

@Julian0021
I have been trying to reproduce this issue. However, my inverter does not show the same behaviour.

Are you running the latest firmware?

Should be:

dtu_hw_version: "H00.01.00"
dtu_sw_version: "V00.01.11"
inverter_hw_version: "H00.04.00"
inverter_sw_version: "V01.00.08"

Maybe it has to do with the way you block Internet access?

@dicer HACS is the home assistant community store you can use to install this component:
https://hacs.xyz

[Julian0021]

@suaveolent

I am running dtu SW version V01.01.09, otherwise its the same

So maybe this issue didnt exist on older firmware?

I block internet out using a traffic rule on my unifi gateway which applies to the vlan the dtu is in.

[suaveolent]

@suaveolent

I am running dtu SW version V01.01.09, otherwise its the same

So maybe this issue didnt exist on older firmware?

I block internet out using a traffic rule on my unifi gateway which applies to the vlan the dtu is in.

Which device are you using? this is not a HMS-XXXW-2T device right? Are you using DTU-Wlite or similar?

[Julian0021]

Which device are you using? this is not a HMS-XXXW-2T device right? Are you using DTU-Wlite or similar?

I am running the HMS-800W-2T. No DTU other than the integrated one. Maybe this version isnt yet available for your region? I live in Germany.

[suaveolent]

Which device are you using? this is not a HMS-XXXW-2T device right? Are you using DTU-Wlite or similar?

I am running the HMS-800W-2T. No DTU other than the integrated one. Maybe this version isnt yet available for your region? I live in Germany.

That is weird indeed. Especially, since the previous firmware versions started with V00. Did you perform an upgrade via hoymiles cloud or did the inverter ship with this version?

[Julian0021]

Which device are you using? this is not a HMS-XXXW-2T device right? Are you using DTU-Wlite or similar?

I am running the HMS-800W-2T. No DTU other than the integrated one. Maybe this version isnt yet available for your region? I live in Germany.

That is weird indeed. Especially, since the previous firmware versions started with V00. Did you perform an upgrade via hoymiles cloud or did the inverter ship with this version?

Sorry. It seems I have mixed something up. My versions are:

Inverter SW Version V01.01.09
Inverter HW Version H00.04.00

DTU SW Version V00.01.11
DTU HW Version H00.01.00

[Julian0021]

I was prompted to update the device upon first installation, which I did (4 days ago)

[suaveolent]

Got it.
So only the inverter firmware is different.

Can you maybe try something different: instead of blocking the inverter via firewall rules, can you just unplug your Internet connection and check if the issue still persists?

[Julian0021]

Got it.

So only the inverter firmware is different.

Can you maybe try something different: instead of blocking the inverter via firewall rules, can you just unplug your Internet connection and check if the issue still persists?

I just tested this, exactly the same behavior

[suaveolent]

Got it.
So only the inverter firmware is different.
Can you maybe try something different: instead of blocking the inverter via firewall rules, can you just unplug your Internet connection and check if the issue still persists?

I just tested this, exactly the same behavior

Hm.
What update interval are you using?

[Julian0021]

The default value of 35

[Julian0021]

All sensors (including dtu) report the same value they do at night for some readings when its disconnected from the internet

[suaveolent]

That is some weird issue you have.

I have blocked my inverter from Internet access since yesterday morning and still cannot reproduce the issue.
Only difference I can see so far is your inverter SW version. Maybe hoymiles introduced sth. in the new SW version which triggers this effect.

You can try updating to the latest v0.2.0 version and see if there is an improvement (although there should not really be one).

I will see if I can implement a workaround in one of the upcoming versions to mitigate this issue. The problem, however, seems to come from the DTU and not the custom component.

[Julian0021]

That is some weird issue you have.

I have blocked my inverter from Internet access since yesterday morning and still cannot reproduce the issue.

Only difference I can see so far is your inverter SW version. Maybe hoymiles introduced sth. in the new SW version which triggers this effect.

You can try updating to the latest v0.2.0 version and see if there is an improvement (although there should not really be one).

I will see if I can implement a workaround in one of the upcoming versions to mitigate this issue. The problem, however, seems to come from the DTU and not the custom component.

No question about it. The dtu seems to behave weirdly when disconnected from the cloud. Not really a bug from the integration, but I was hoping you could mitigate it.

[suaveolent]

Noticed today that since yesterday I was indeed experiencing the same issue.
I will keep you updated if I find a solution for it

[O-misses]

I've got a very similar behavior:
HMS-800W-2T
dtu_hw_version: "H00.01.00"
dtu_sw_version: "V00.01.11"
inverter_hw_version: "H00.04.00"
inverter_sw_version: "V01.00.08"
60s update intervall. Wifi signal strength 58%
Internet access blocked via firewall (Fritz Box router)
Connection loss is somewhat regular (see graph), but not every 3min. Actual energy delivery is not affected.

I guess it is a problem within the DTU firmware, and has nothing to do with this HA integration. When I use the S-miles installer app to access the inverter over its own wifi, the displayed values often freeze after some time. Although there are clouds in front of the sun, the values stay the same. Maybe the DTU is simply unresponsive whilst trying to send data to the cloud?

[suaveolent]

I've got a very similar behavior: HMS-800W-2T dtu_hw_version: "H00.01.00" dtu_sw_version: "V00.01.11" inverter_hw_version: "H00.04.00" inverter_sw_version: "V01.00.08" 60s update intervall. Wifi signal strength 58% Internet access blocked via firewall (Fritz Box router) Connection loss is somewhat regular (see graph), but not every 3min. Actual energy delivery is not affected.

You graph seems to make sense since you are using a 60s polling interval as opposed to 35 seconds, which would explain the larger gaps.
If I could find out a reliable way whether the DTU is unresponsive, I could maybe implement a workaround.

[IIChrisII]

HMS-800W-2T
dtu_hw_version: "H00.01.00"
dtu_sw_version: "V00.01.11"
inverter_hw_version: "H00.04.00"
inverter_sw_version: "V01.00.08"
update interval: 35 (default)

I have exactly the same disconnections. My assumption is that the dtu is trying to open the socket to colud ip and this blocks the complete dtu until socket connection timeout. To prove that we would need a fake machine at that cloud ip inside virtual lan sending back connection refused. But I think building up that scenario is to much effort for a simple test.

However @suaveolent could you add a delay for setting entities unavailable? I mean if the dtu does not response, could you keep all values of the entities and set them finally unavailable after dtu is not responding for more than 70 seconds (two default cycles should be enough)?

[suaveolent]

HMS-800W-2T dtu_hw_version: "H00.01.00" dtu_sw_version: "V00.01.11" inverter_hw_version: "H00.04.00" inverter_sw_version: "V01.00.08" update interval: 35 (default)

I have exactly the same disconnections. My assumption is that the dtu is trying to open the socket to colud ip and this blocks the complete dtu until socket connection timeout. To prove that we would need a fake machine at that cloud ip inside virtual lan sending back connection refused. But I think building up that scenario is to much effort for a simple test.

However @suaveolent could you add a delay for setting entities unavailable? I mean if the dtu does not response, could you keep all values of the entities and set them finally unavailable after dtu is not responding for more than 70 seconds (two default cycles should be enough)?

Yes, that might be a good idea. I will look into this.

[DirkBaumeister]

Hi,
any update on this topic? :) I am currently deciding which inverter I wanna get and this behaviour when the internet is blocked would be not so great.

Thanks!

[suaveolent]

Hi, any update on this topic? :) I am currently deciding which inverter I wanna get and this behaviour when the internet is blocked would be not so great.

Thanks!

I might be able to implement a workaround which only sets the data to 0 after a certain delay. However, since the inverter does not respond, the displayed data will also be not accurate and only display the data from the last response.

So in the end, Hoymiles needs to fix this. Maybe you can file a bug report and hope for a firmware update?

[DirkBaumeister]

So I guess it's the best for now to drop the request to the hoymiles cloud entirely to prevent this lockup I guess :) Unfortunatly I don't have this inverter to test it. Anyone that has the ability to test this with a firewall or something? :)

[IIChrisII]

I think we have to differenciate between human observation by watching to sensors in Home Assistant and concret data provided by the device. If you look to the log of the device in Home Assistant all sensors of the HMS gets unavailable and then comes back. This produces the 0-Values for a short time. My conclusion (as described above) is, that the DTU (which is only the communication interface) tries to send Data to the hoymiles cloud service (the fixed dns ip is already known), this blocks due to the firewall rule but HMS is waiting for connection timout and this makes the complete interface unavailable -> Home Assistant Sensors are going unavailable -> logger is writing 0 Values. Then Connection Timout occurs and DTU responds to requests from HA again -> correkt values are shown again.

While DTU ist waiting for connection to be established, home assistant sensors get unavailable/0. The Inverter (not DTU) is still working and producing korrekt values but these can not be requested because of the DTU. (This is just a logical assumption which is supported by the Log of the DTU in Home assistant. At the time, the readings get 0 you will see, the dtu is disconnected, then comes back).

[IIChrisII]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

[suaveolent]

I think we have to differenciate between human observation by watching to sensors in Home Assistant and concret data provided by the device. If you look to the log of the device in Home Assistant all sensors of the HMS gets unavailable and then comes back. This produces the 0-Values for a short time. My conclusion (as described above) is, that the DTU (which is only the communication interface) tries to send Data to the hoymiles cloud service (the fixed dns ip is already known), this blocks due to the firewall rule but HMS is waiting for connection timout and this makes the complete interface unavailable -> Home Assistant Sensors are going unavailable -> logger is writing 0 Values. Then Connection Timout occurs and DTU responds to requests from HA again -> correkt values are shown again.

While DTU ist waiting for connection to be established, home assistant sensors get unavailable/0. The Inverter (not DTU) is still working and producing korrekt values but these can not be requested because of the DTU. (This is just a logical assumption which is supported by the Log of the DTU in Home assistant. At the time, the readings get 0 you will see, the dtu is disconnected, then comes back).

This perfectly summarises the problem.
As I said, I could implement a workaround to "fix" the graph, but if you are using an automation based on the value reported, it will only report an outdated value and not the actual value.

[DirkBaumeister]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

[suaveolent]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

This was also an idea I had for the firmware update.
Another thing we could try: The get-config request reports back:

server_domain_name: "dataeu.hoymiles.com"

We could even try setting that value to our Home Assistant instance and then provide a response.
However, this still means bending the DNS responder.

[DirkBaumeister]

Yes, absolutely.
Is the inverter somewhat operational even without panels attached? So maybe someone (Or me, if I get my hands on one) could debug this even without going "full solar installation" already.

Edit: Don't think so because it only is accessible when there is sun (= panels attached) right?

[suaveolent]

Yes, absolutely. Is the inverter somewhat operational even without panels attached? So maybe someone (Or me, if I get my hands on one) could debug this even without going "full solar installation" already.

Edit: Don't think so because it only is accessible when there is sun (= panels attached) right?

Yes, you need panels and/or battery.

[DirkBaumeister]

Too bad :D
Hmm. Maybe I can provide an internet "fake endpoint" somehow later. @suaveolent Any chance to test your idea of changing the api endpoint on your test unit? This wouldn't require dns rewrite at all because it would be a public server with valid ssl certificates. If so, please let me know, than I can send you an endpoint (personally somehow) :)

[IIChrisII]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

i would try this. But actually im struggeling because i block the communication simply by fritzbox. How do I ensure that DNS requests for 8.8.8.8 are redirected to my DNS server but the rest of the communication from the device is blocked?

[DirkBaumeister]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

i would try this. But actually im struggeling because i block the communication simply by fritzbox. How do I ensure that DNS requests for 8.8.8.8 are redirected to my DNS server but the rest of the communication from the device is blocked?

That's not so trivial if you haven't worked with iptables or similar before

[DirkBaumeister]

@suaveolent You can actually use something like https://webhook.cool
This would provide you an endpoint, for example: https://abc.webhook.cool which you can (hopefully) set as api endpoint

[IIChrisII]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

i would try this. But actually im struggeling because i block the communication simply by fritzbox. How do I ensure that DNS requests for 8.8.8.8 are redirected to my DNS server but the rest of the communication from the device is blocked?

That's not so trivial if you haven't worked with iptables or similar before

have done this before but it's definetly not my daily business and im not an (network)administrator. Maybe you can help. DNS Server is set up to answer with 0.0.0.0 for "dataeu.hoymiles.com". Now i woul set up a static route for 8.8.8.8 to my dns server, right? What is the network/subnetmask of 8.8.8.8?

[DirkBaumeister]

same result with REJECT as for DROP. My old Unifi gateway (USG) does not support DNS "masquerading", so no more logs from my side

Do i correctly understand that you rejected (not blocked) somehow the ip connections to 8.8.8.8?

Would be cool to see what the inverter does if someone could response to dns request for dataeu.hoymiles.com with the ip address 0.0.0.0, like pihole does. This should result in an abort of the request hopefully.

i would try this. But actually im struggeling because i block the communication simply by fritzbox. How do I ensure that DNS requests for 8.8.8.8 are redirected to my DNS server but the rest of the communication from the device is blocked?

That's not so trivial if you haven't worked with iptables or similar before

have done this before but it's definetly not my daily business and im not an (network)administrator. Maybe you can help. DNS Server is set up to answer with 0.0.0.0 for "dataeu.hoymiles.com". Now i woul set up a static route for 8.8.8.8 to my dns server, right? What is the network/subnetmask of 8.8.8.8?

Hmmm, I don't think a static route will help you here. You have to modify the request via iptables and DNAT in the PREROUTING process that it "bends" the request to 8.8.8.8 to your own ip address (Like mentioned here: https://askubuntu.com/a/592398 )

EDIT:
A basic rule would look like this:

iptables -A PREROUTING ! -s <DNS SERVER IP>/32 ! -d <DNS SERVER IP>/32 -p tcp -m tcp -m iprange --src-range <IP RANGE START>-<IP RANGE END> --dport 53 -j DNAT --to-destination <DNS SERVER IP>:53
iptables -A PREROUTING ! -s <DNS SERVER IP>/32 ! -d <DNS SERVER IP>/32 -p udp -m udp -m iprange --src-range <IP RANGE START>-<IP RANGE END> --dport 53 -j DNAT --to-destination <DNS SERVER IP>:53

DNS SERVER IP = The ip address of your dns server
IP RANGE START = The first ip of client that should be modified
IP RANGE END = The last ip of client that should be modified

[IIChrisII]

Pity. I don't think I can do that with the FritzBox ;).

[DirkBaumeister]

Pity. I don't think I can do that with the FritzBox ;).

Probably not ;)

[DirkBaumeister]

So, anyone still interested to debug this?

[IIChrisII]

Of course, in relation to the benefits, the workaround with continuous sensor values would be best. Even if the data may be different in time, we are talking about a time window of 30 seconds. If you consider that many inverters (including the Hoymiles) have a significantly higher interval as standard, this is negligible. Apart from that, the PowerLimit cannot/should not be set anyway. In OpenDTU there is non_persistent_power_limit and persistent_power_limit. As long as this is not analogue, you shouldn't use this to implement zero feed-in anyway, which in turn makes non-changing sensor values negligible for 30 seconds.

[O-misses]

Rather than rolling forward or "faking" the values I'd prefer waiting for a firmware fix from Hoymiles. Someone already asked them in a german discussion board https://www.photovoltaikforum.com/thread/208190-hoymiles-hms-800w-2t-mit-wifi-integriert/?postID=3707144#post3707144
Maybe someone could test out and confirm: Whilst the device is not responsive, the live values in the S-Miles App freeze as well, don't they?
If that is the case, I would be quite positive about a firmware update directly from Hoymiles somewhen in the future. And after all it's a fairly new device which should receive active support.

[DirkBaumeister]

Rather than rolling forward or "faking" the values I'd prefer waiting for a firmware fix from Hoymiles. Someone already asked them in a german discussion board https://www.photovoltaikforum.com/thread/208190-hoymiles-hms-800w-2t-mit-wifi-integriert/?postID=3707144#post3707144 Maybe someone could test out and confirm: Whilst the device is not responsive, the live values in the S-Miles App freeze as well, don't they? If that is the case, I would be quite positive about a firmware update directly from Hoymiles somewhen in the future. And after all it's a fairly new device which should receive active support.

I guess anyone would prefer a firmware based fix but until then: Why not try to find a workaround? :)

[IIChrisII]

Another point is, how motivated the manufacturer will be to release a firmware update for a small group that definitely doesn't do what it's supposed to do, -> transmit data nicely. If Hoymiles wanted to give you the possibility not to send them your data, they would have build some kind of option. From perspective of the manufacturer it's more some kind of feature then a bug ;).
From an economic point of view, there is also no reason to allocate money to further development so that they can ultimately collect less data. In summary, the chances are high that there will not be another firmware update (in the near future).

[DirkBaumeister]

So, anyone got updates on this one? Or anyone interested to debug this some more? :)

[SIT-GH]

I also have the problems mentioned above with connection lost every three minutes with my HMS-800W-2T. The cloud access is blocked (FritzBox). So, a workaround in the HA implementation until Hoymiles (hopefully) brings a FW update would be a good thing. I think not updating the value instead writing 0's if only one readout is affected could be a termporary solution.

DUT:
H00.01.00
V00.01.11

Inverter:
H00.04.00
V01.00.08

[stheid]

I think the best that this extension can do is report "unknown" instead of 0 and then filter the values in home assistant. Maybe someone finds a way to patch the firmware :D

[suaveolent]

Doing some testing today.
I noticed that the issue does not occur if access to the Internet is blocked after the inverter is rebooted.

If, however, you block the Internet and restart the DTU, then the issue immediately occurs.

I'm now testing the workaround and if it works as intended, will push a fix later this day.

[suaveolent]

Latest version is released, please reopen issue if the problem persists.

[N3rdix]

Will give it a try tomorrow and block the internet connection for the DTU once more.
I never did a restart of the DTU in my recent tests, so I am curious how it behaves now...

[LeoSum8]

Hi all,
I just connected my HMS-800W-2T to HA with this integration. Thank you @suaveolent for this!!
I installed the latest 0.2.3 via HACS. I am still seeing the behaviour described above by other:

I can also see that this is due to the DTU loosing connection to my fritzbox.

I left the interval at the default 35.

However I have not yet actively blocked the DTUs Internet Access, even though I intended to do so.
But the connection seems to be blocked, since I cannot update the firmware. Connection is established to the router but fails to the cloud.

[N3rdix]

I can also see that this is due to the DTU loosing connection to my fritzbox.

This might be the reason for the connection drops, did you check the signal strength in the HA integration (device DTU)?

But the connection seems to be blocked, since I cannot update the firmware. Connection is established to the router but fails to the cloud.

If you did not block it then I assume it's a different issue. Can you access the Hoymiles Cloud in general? Are you using any kind of local DNS resolver which might block the requests?
I was able to trigger the firmware update (via Web, not via App) without issues some weeks ago.

[LeoSum8]

Thank you for the hint.
That brought me to retry the firmware-update again. I followed theses steps (google-translated to english) and it worked finally.

Now I don't have the dropouts anymore.

Also this way the firmware update runs via the phone's hotspot and I can block the DTU's internet access before connecting it to my fritzbox. So it never reached the internet.