Closed keinprofi closed 1 year ago
reserve85
commented
1 year ago man muß mindestens solange warten bis er das Limit akzeptiert (/ack_pwr_limit), erst dann funktioniert er damit auch.
@knickohr: Geht das überhaupt über die webAPI? Finde das nur via MQTT.
knickohr
commented
1 year ago Ich habe die API nicht angeschaut. Wenn es da nicht drin ist, wäre die nächste Alternative das Warten auf den gesetzten Power-Limir Wert :
/ch0/active_PowerLimit
Keine Ahnung ob das auch in der API drin ist. Der Wert kommt aber verzögert, da war das ack schon da. Vielleicht bei der API anders ?
MetaChuh
commented
1 year ago @knickohr & @reserve85
in der api ist es im endpoint http://
das liefert dann ein array mit folgenden werten zurück:
(
[id] => 0
[enabled] => 1
[name] => HM-800
[serial] => 123412341234
[version] => 10010
[power_limit_read] => 100
[ts_last_success] => 1691590772
[ch] => Array
(
[0] => Array
(
[0] => 231.2
[1] => 0.72
[2] => 165.4
[3] => 49.96
[4] => 1
[5] => 32.3
[6] => 197.626
[7] => 1041
[8] => 173.7
[9] => 95.222
[10] => 0.1
)
[1] => Array
(
[0] => 30
[1] => 2.97
[2] => 88.9
[3] => 536
[4] => 105.775
[5] => 21.683
)
[2] => Array
(
[0] => 30.3
[1] => 2.8
[2] => 84.8
[3] => 505
[4] => 91.851
[5] => 20.683
)
)
[ch_name] => Array
(
[0] => AC
[1] => JKM410M Bottom
[2] => JKM410M Top
)
[ch_max_pwr] => Array
(
[0] =>
[1] => 410
[2] => 410
)
)greetings metachuh
reserve85
commented
1 year ago @MetaChuh: power_limit_read ändert sich allerdings erst nachdem die neuen Werte vom Inverter zurückgelesen werden. Das kann u.U. ziemlich lange dauern, je nach Intervall.
Für die RestAPI Kommunikation ohne MQTT wäre eine Acknowledge-Möglichkeit für die Limit-Änderung (ähnlich MQTT) gut. Ggf. könnte man bei dem Limit setzen eine (optionale) ID mitsenden und über REST ein ACK-Field mit der letzten erfolgreichen ID zur Verfügung stellen.
knickohr
commented
1 year ago Jetzt haben wir diesen Issue total vergewohlwurstelt 😱 Das hat doch überhaupt nichts mehr mit dem Thema zu tun. Kann man das irgendwie absplittern und in einen neuen Issue rein pappen ?
mit dem Power-Limit über MQTT bin ich auch noch nicht so glücklich. Hier sollte man QoS=2 machen, sowohl für das Set-Limit als auch für das ACK. Ansonsten kann das schon mal im Nirvana verschwinden und man wartet ewig auf ein ACK 😲
MetaChuh
commented
1 year ago @MetaChuh: power_limit_read ändert sich allerdings erst nachdem die neuen Werte vom Inverter zurückgelesen werden. Das kann u.U. ziemlich lange dauern, je nach Intervall.
ja, gibt latenz, dauert bei mir aber nur ca 10 sek. bis zum ack. deine latenz kannst du leicht in der dtu austesten, einfach manuell power limit setzen und bei live nachschauen wann er die änderung anzeigt. am shelly power meter siehst du dann auch gleich den anspeise anstieg oder abfall.
ich zb. warte auf das ack bevor ich eine weitere änderung sende, und sende kein limit wenn bei mir $current_power_limit == $power_limit_read der dtu ist.
Für die RestAPI Kommunikation ohne MQTT wäre eine Acknowledge-Möglichkeit für die Limit-Änderung (ähnlich MQTT) gut. Ggf. könnte man bei dem Limit setzen eine (optionale) ID mitsenden und über REST ein ACK-Field mit der letzten erfolgreichen ID zur Verfügung stellen.
ich verwende auch nur pure php und dtu, ohne middleware. php statt python, wegen der einfachen web gui aufbereitung, ohne eine weitere code instanz zu benötigen. muss mir bei zeiten mal deinen code anschauen, habe bis jetzt nur gutes gehört 👍
ich teste mal den letzten turbo commit von @lumapu (thx, by the way) 👍 edit: power_limit_ack getestet (v0.7.29 & v0.7.30) funzt perfekt, vielen dank 👍
greetings metachuh
knickohr
commented
1 year ago Die 30 ist OK, Schwuppdizität hat nicht gelitten 😂, 29 habe ich gar nicht angeschaut 😇
Das mit der Alarm-Message schaue ich mir mal an, war schon lange ein Punkt, was aufgestoßen ist. Sind da jetzt alle Meldungen drin oder nur die letzte ? Klar, es wird immer nur eine gesendet.
Wurde nochwas an MQTT gemacht ? QoS für die Piwer-Limit Messages ?
wir sollten den Issue hier zu bekommen, ansonsten wird das der Feld-Wald-Wiesen-Durchrinander-Issue 😱
lumapu
commented
1 year ago ich versuche jeder Version, die ich veröffentliche eine neue Nummer zu geben zwecks Nachvollziehbarkeit. Daher so schnell 29 und 30 😊
Nein bzgl. QoS haben ich noch nichts gemacht, evtl heute Abend.
Die Alarm Messages:
/api/inverter/alarm/[ID]Invertert started drin stehenreserve85
commented
1 year ago @lumapu Mega, Danke für die REST Erweiterung ich schaue mir das dann demnächst an.
knickohr
commented
1 year ago @lumapu
QoS=2 aber bitte nur bei den 3 Messages für das Power-Limit, also :
Wobei sich bei der letzten Message streiten läßt ob da wirklich QoS=2 sein muß, da könnte auch 1 reichen, vorausgesetzt das Ack kommt sauber und auch nur einmal.
Alles andere würde sicher nur den Rechenaufwand und den Traffic unnötig erhöhen, bzw. sicherlich wieder die Schwuppdizität leiden lassen 😅
Hardware
Modelname: __ Retailer URL: __
nRF24L01+ Module
Antenna:
Power Stabilization:
Version / Git SHA:
Version: 0.7.25 Github Hash: ___
Build & Flash Method:
Debugging:
Mit der 0.6.9 lief alles soweit gut. Lediglich der P_AC total wird in letzter Zeit nicht mehr regelmäßig ausgelesen. Deswegen habe ich heute ein Update auf die 0.7.25 gewagt und bekam danach keine Verbindung zu den WR mehr. Nach einem Downgrade auf die 0.6.9 lief es wieder.
Woran kann das liegen?