You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ich hätte da mal ein Gedanken-Experient.
Wenn ich mir den Programmcode des neuen isss.py sowie die service.sh ansehe,
dann hätte ich da ein Frage....
Für die Buchsen-Box wurde bis zur version 1.9.x ein eigener Daemon buchse.py verwendet.
Dieser wurde gestart wenn die Box Standalone betrieben wurde.
Beim "Nur-Lade Punkt" (hier im folgenden als slave benannt) wurde der isss.py statt dessen gestaret
(genauer, es wurde von cron5min.sh innerhalb von 5 Minuten umgeschaltet (start/stop))
also vorher:
Standone -> buchse.py
Slave -> isss.py
Seit Umpdate 1.9.x (keine Ahnung irgendwo bei 288)
wird nun der isss.py für alle Fälle benutzt.
Wenn ich also eine Buchse auf Slave schalte, wird der isss beibhalten, weil er wurde ja auch schon
für den "standalone" Betrieb verwendet.
Die Master meldet sich dann via mqtt beim Slave und gibt ihr ihre "parenWB" IP-Adresse bekannt.
der isss sendet dann seine Daten direkt zu Master (eben zur ParentWB)
Soweit so gut.
Wenn ich nun so einen Buchse (oder einen openWB-Daemon?) wieder zurück auf Standalone schalte
wird die Variable parentWB nicht gelöscht.
Soweit ich das bisher verstehe führt das dazu das:
Der isss.py der ja für die Buchsen-Box weiterhin verwenden wird, wird weiterhin seine Daten zur u.U, nicht mehr vorhanden ehemaligen parentWB senden.
Auch die Master wird mit Daten bezüglich eines ehemaligen als "exterm OpenWB" konfigurierten LP beschickt.
Beides bringt Verwirrung für beide Boxen.
Falls ich recht habe, sollte der isss.py die Variable parentWB nur beim "isss=1" beachten.
und nur dann Daten zur Master senden.
Der alte "buchse.py" hatte die parentWB nicht verwendet.
Auch der alte "autoevse.py" der DUO hatte die parentWB nicht verwendet.
The text was updated successfully, but these errors were encountered:
Ich hätte da mal ein Gedanken-Experient.
Wenn ich mir den Programmcode des neuen isss.py sowie die service.sh ansehe,
dann hätte ich da ein Frage....
Für die Buchsen-Box wurde bis zur version 1.9.x ein eigener Daemon buchse.py verwendet.
Dieser wurde gestart wenn die Box Standalone betrieben wurde.
Beim "Nur-Lade Punkt" (hier im folgenden als slave benannt) wurde der isss.py statt dessen gestaret
(genauer, es wurde von cron5min.sh innerhalb von 5 Minuten umgeschaltet (start/stop))
also vorher:
Standone -> buchse.py
Slave -> isss.py
Seit Umpdate 1.9.x (keine Ahnung irgendwo bei 288)
wird nun der isss.py für alle Fälle benutzt.
Wenn ich also eine Buchse auf Slave schalte, wird der isss beibhalten, weil er wurde ja auch schon
für den "standalone" Betrieb verwendet.
Die Master meldet sich dann via mqtt beim Slave und gibt ihr ihre "parenWB" IP-Adresse bekannt.
der isss sendet dann seine Daten direkt zu Master (eben zur ParentWB)
Soweit so gut.
Wenn ich nun so einen Buchse (oder einen openWB-Daemon?) wieder zurück auf Standalone schalte
wird die Variable parentWB nicht gelöscht.
Soweit ich das bisher verstehe führt das dazu das:
Der isss.py der ja für die Buchsen-Box weiterhin verwenden wird, wird weiterhin seine Daten zur u.U, nicht mehr vorhanden ehemaligen parentWB senden.
Auch die Master wird mit Daten bezüglich eines ehemaligen als "exterm OpenWB" konfigurierten LP beschickt.
Beides bringt Verwirrung für beide Boxen.
Falls ich recht habe, sollte der isss.py die Variable parentWB nur beim "isss=1" beachten.
und nur dann Daten zur Master senden.
Der alte "buchse.py" hatte die parentWB nicht verwendet.
Auch der alte "autoevse.py" der DUO hatte die parentWB nicht verwendet.
The text was updated successfully, but these errors were encountered: