lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
947 stars 222 forks source link

[Bug]0.7.26 Oscillating between not producing / producing #1077

Closed SvHeMobile closed 1 year ago

SvHeMobile commented 1 year ago

Platform

ESP8266

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

nothing

Connection picture

Version

0.7.26

Github Hash

-

Build & Flash Method

AhoyDTU Webinstaller

Setup

Update from 0.6.9 to 0.7.26

Debug Serial Log output

.

Error description

After update to 0.7.26 system oscillates between producing and not producing. 0.6.9 worked fine.

DonKracho commented 1 year ago

I'm new to the great Ahou-DTU project. I just did setup it yesterday with a Wemos D1 Mini, nRF24L01+ plus using the on board circuit antenna connected to a Hoymiles HM-800.

I can confirm, that I'm geting alternating 0 and real values too in the Live View, even if the distance beween the inverter and the Ahoi-DTU is only a few meters. The yield values keep up to date. The 0 values are also reported via MQTT.

lumapu commented 1 year ago

do you use power limit control?

SvHeMobile commented 1 year ago

Hi, no. Rather simple setup. 2xHM600, 4 panels, no limits, no display, just MQTT. Von meinem iPhone gesendetAm 08.08.2023 um 00:41 schrieb Lukas Pusch @.***>: do you use power limit control?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

DonKracho commented 1 year ago

I do not use limit control. For me the issue is related to https://github.com/lumapu/ahoy/issues/1035 The setting "Reset values when the inverter status is not available' is checked by default. Unchecking this setting and savivg did fix the issue for me.

SvHeMobile commented 1 year ago

I do not use limit control. For me the issue is related to #1035 The setting "Reset values when the inverter status is not available' is checked by default. Unchecking this setting and savivg did fix the issue for me.

Jep, looks like this did the trick for me too. Probably bad connection that did not materialize due to persistence of values.

LeSpocky commented 1 year ago

I would say the problem is still there if you uncheck that Reset values when inverter status is 'not available' setting, it just does not lead to such easily visible consequences. For me with two inverters it looks like they are alternating with their last success value. Each 30 seconds I get MQTT values and the 'last success' value is only updated for one of the inverters, which means the 'last success' timestamp increases by 60 seconds for a single inverter every other 30 seconds. You can see it easily in MQTT output:

alex@lemmy ~/adm % mosquitto_sub -h mqtt -t 'ahoy-dtu/+/last_success' -v -F '@s \e[92m%t \e[96m%p\e[0m'
1691829542 ahoy-dtu/HM400-Balkon/last_success 1691829520
1691829542 ahoy-dtu/HM600-Balkon/last_success 1691829490
1691829551 ahoy-dtu/HM400-Balkon/last_success 1691829520
1691829551 ahoy-dtu/HM600-Balkon/last_success 1691829550
1691829581 ahoy-dtu/HM400-Balkon/last_success 1691829580
1691829581 ahoy-dtu/HM600-Balkon/last_success 1691829550
1691829611 ahoy-dtu/HM400-Balkon/last_success 1691829580
1691829611 ahoy-dtu/HM600-Balkon/last_success 1691829610
1691829641 ahoy-dtu/HM400-Balkon/last_success 1691829640
1691829641 ahoy-dtu/HM600-Balkon/last_success 1691829610
1691829671 ahoy-dtu/HM400-Balkon/last_success 1691829640
1691829671 ahoy-dtu/HM600-Balkon/last_success 1691829670
1691829701 ahoy-dtu/HM400-Balkon/last_success 1691829700
1691829701 ahoy-dtu/HM600-Balkon/last_success 1691829670
1691829731 ahoy-dtu/HM400-Balkon/last_success 1691829700
1691829731 ahoy-dtu/HM600-Balkon/last_success 1691829730
1691829761 ahoy-dtu/HM400-Balkon/last_success 1691829760
1691829761 ahoy-dtu/HM600-Balkon/last_success 1691829730
1691829791 ahoy-dtu/HM400-Balkon/last_success 1691829760
1691829791 ahoy-dtu/HM600-Balkon/last_success 1691829790
1691829821 ahoy-dtu/HM400-Balkon/last_success 1691829820
1691829821 ahoy-dtu/HM600-Balkon/last_success 1691829790
1691829851 ahoy-dtu/HM400-Balkon/last_success 1691829820
1691829851 ahoy-dtu/HM600-Balkon/last_success 1691829850
1691829881 ahoy-dtu/HM400-Balkon/last_success 1691829880
1691829881 ahoy-dtu/HM600-Balkon/last_success 1691829850
1691829911 ahoy-dtu/HM400-Balkon/last_success 1691829880
1691829911 ahoy-dtu/HM600-Balkon/last_success 1691829910
1691829941 ahoy-dtu/HM400-Balkon/last_success 1691829940
1691829941 ahoy-dtu/HM600-Balkon/last_success 1691829910

This is also observable in the web interface. The grey field is never the same timestamp for both inverters, but 30 seconds difference, for example:

  1. Last received data requested at: 2023-08-12, 10:45:40
  2. Last received data requested at: 2023-08-12, 10:46:10

And after the next update:

  1. Last received data requested at: 2023-08-12, 10:46:40
  2. Last received data requested at: 2023-08-12, 10:46:10
lumapu commented 1 year ago

@LeSpocky maybe you don't know: for now the inverval is more like a timeout - every 30s an inverter is asked for its values. This should be changed in future. This would explain the behaviour you described.

LeSpocky commented 1 year ago

@lumapu I was informed in Discord already, that the actual behavior when everything is fine looks like round robin and that this is normal. Sorry for the noise.