Bayernlüfter und ioBroker
-
@mcm1957 vielleicht kannst du bei Gelegenheit mal auf die onStateChange-Methode schauen, das kommt mir etwas komisch vor mit der realid und dem
await this.setState(realid, state.val, true);bzw.await this.setState(realid, false);
Auszug aus der Methode:async onStateChange(id, state) { if (!state) return; if(state.val == false) return; const id_splits = id.split('.'); const realid = id_splits[2] + '.' + id_splits[3] + '.' + id_splits[4]; const device = await this.GetDeviceByName(id_splits[2]); this.log.debug('onStateChange: id: ' + id + ' Device ' + device.name + ' IP ' + device.ip + ' Port ' + device.port + ' Value ' + state.val); if(id.includes('.setSpeed')) { const res = await this.sendHttpRequest('http://' + device.ip + ':' + device.port + '/?speed=' + state.val, device.name); if(!res) return this.log.error('An error has occured while trying to set Device ' + device.name + ' Speed to ' + state.val); await this.setState(device.name + '.states.speed_in', state.val, true); await this.setState(device.name + '.states.speed_out', state.val, true); await this.setState(realid, state.val, true); } else if(id.includes('.powerOn')) { const res = await this.sendHttpRequest('http://' + device.ip + ':' + device.port + '/?power=on'); if(!res) return this.log.error('An error has occured while trying to power on device ' + device.name); await this.setState(device.name + '.states.systemon', 1, true); await this.setState(realid, false); } //... }Ich vermute da liegt auch irgendwie der Fehler, dass sich der buttonAuto in eine Endlosschleife begibt (da wird die Methode onStateChanged immer wieder neu aufgerufen). Aber das mit dem ack hab ich ehrlicherweise noch nie so ganz verstanden.
Ich hab gerade mal in 3 zufällig ausgewählte Adapter reingeschaut und alle handhaben das irgendwie anders. Und im offiziellen Adapter-Template wird das ack gar nicht behandelt in der onStateChange Methode. -
@boriswerner
Ja, das ist zumindest unsauber (um nicht nach 2s schaun falsch zu schreiben)onState change muss state changes bei EIGENEN States (States der AdapetrInstanz) ignorieren wenn ack !== false ist.
Was der State realid ist müßte ich mir erst ansehen. Dass hier (implizit) mit state.sck===false geschrieben wird (da 3ter Paramater fehlt) wär jedenfalsl einen Blick wert.
Dass im Template ACK nicht behandelt wird ist unsinnig. Dazu gibts auch ein Issue nur noch niemand der das umgesetzt hat.
Prinzipiell gilt:
ack=false heißt es wird eine Änderung an den Adapter und damit an das Gerät gesendet. Dies betrifft typisch alle externen Befehle (vis stellt einen Paramater um, javaScript verändert was zusw.) ack===false ist also typisch INPUT in Bezug auf den Adapter von Userseite aus gesehen.
ack=true setzt der Adapter wenn er einen Wert vom Gerät bekommen (= bestätigt bekommen) hat. ack===true ist also typisch OUTPUT in Bezug vom Adapter zum User
onStateChange auf EIGENE States sind daher (typisch) zu ignorieren wenn ack===false ist. Schreibt der User einen neuen Wert rein, dann muss akc===false sein und der Adapetr reagieren. Bestätigt der Adapter den Wert und setzt ack=true dann soll er ja nicht mehr drauf reagieren.
onStateChange auf FREMDE States (weil der Adapeter z.B. den Output eines anderen Adapters monitored) sollten typisch nur auf bestätigte Werte (ack===true) reagieren. Aber es kann auch sein, dass der Adapter bewußt auch auf unbestätogten Input anderer Adaüter regieren will. Das kann nur im Einzelfall bestimmt werden.
Und dann gibts noch Convinience Ausnahmen. Beispielsweise verwenden einige wenige Adapter das Sbscriptien System um auch auf eigene Ändereungen zu regieren. Ist nicht gerade toll, da da ziemlich Overhead anfällt - aber im Einzelfall kann es sinnvoll sein. Und bei 0_userdata wird oft das ack Flag auch ignoriert um Diskussionen über den richtigen Schreibvorgang dort zu reduzieren...
Aber was den Byernlüfter betrifft:
onStateChange auf eigenen States (und ich seh mal nur die) sollte bei ack===true ignoriert werden. Fürg das mal ein und teste das.DANKE
-
@boriswerner said in Bayernlüfter und ioBroker:
@negalein bis auf Lüfterspeed sollte das schon funktionieren. Teste gerne mal, wenn du experimentierfreudig bist und das schon einen Mehrwert hätte.
@mcm1957 das mach ich natürlich, ich hab das nur gerade auf schnell-schnell gemacht, sodass es "irgendwie" funktioniert. An einen PR hab ich dann doch noch einen bisschen höheren Qualitätsanspruch
oder soll ich es trotzdem einfach schonmal machen (im Sinne von besser als gar nichts?)Ohne den Code gesehen zu haben kann ich wenig dazu sagen. Aber solange du nicht deine persönliche IP Addresse zu Hause reincodiert hast oder gar Passwörter würd ich sagen jede Verbesserung ist sinnvoll. Es reich vollkommen den Code anzupassen und ggF. einen Eintrag im README.md Changelog zu machen (wobei das kann ggF ich auch
). Alle Anpassungen in io-package.json / package.json (version, news, ...) erfolgen durch den Releasevorgang und sollten explizit NICHT im PR drinnen sein.Da de P´K ja im wesentloichen nur ein (oder 3 glaub ich) Clicks ist erstell einfach mal einen. Eine alpha release ist immer drinnen. Und wenn der derzeitige Code ah nicht mehr läuft da die Hersteller url falsch ist kann es ja nur besser sein.
Der Discord-Link scheint übrigens abgelaufen zu sein, zumindest funktioniert er nicht ("Einladung ungültig - Diese Einladung ist entweder abgelaufen oder du hast nicht die Berechtigung beizutreten")
Ja, issue dazu ist noch offen. Test mal: https://discord.gg/HwUCwsH.
Ansonsten muss ich dich auf Telegramm verweisen oder chattest @Homoran hier im Forum an. Ich nutz discord nicht uns kann daher wenig da helfen (dicord und telegramm werden aber prinzipiell was die Nachrichten betrifft) gespeigelt. -
@mcm1957 sagte in Bayernlüfter und ioBroker:
oder chattest @Homoran hier im Forum an. Ich nutz discord nicht uns kann daher wenig da helfen
dito!
-
@homoran
wer wär da guter Ansprechpartner hier? Weisst du da was ? -
-
@boriswerner sagte in Bayernlüfter und ioBroker:
bis auf Lüfterspeed sollte das schon funktionieren. Teste gerne mal, wenn du experimentierfreudig bist und das schon einen Mehrwert hätte.
hab heute deine Version installiert.
Läuft derzeit unauffällig.
bayernluft.0 2024-12-27 17:09:20.489 info starting. Version 2.0.0-alpha.0 (non-npm: boriswerner/ioBroker.bayernluft#7b7a3e71591d1b2e75fa9e21cc93e4554d226337) in /opt/iobroker/node_modules/iobroker.bayernluft, node: v20.18.1, js-controller: 7.0.3 bayernluft.0 2024-12-27 17:09:20.328 debug States connected to redis: 0.0.0.0:9000 bayernluft.0 2024-12-27 17:09:20.272 debug States create User PubSub Client bayernluft.0 2024-12-27 17:09:20.271 debug States create System PubSub Client bayernluft.0 2024-12-27 17:09:20.225 debug Redis States: Use Redis connection: 0.0.0.0:9000 bayernluft.0 2024-12-27 17:09:20.118 debug Objects connected to redis: 0.0.0.0:9001 bayernluft.0 2024-12-27 17:09:20.114 debug Objects client initialize lua scripts bayernluft.0 2024-12-27 17:09:20.010 debug Objects create User PubSub Client bayernluft.0 2024-12-27 17:09:20.010 debug Objects create System PubSub Client bayernluft.0 2024-12-27 17:09:20.009 debug Objects client ready ... initialize now bayernluft.0 2024-12-27 17:09:19.966 debug Redis Objects: Use Redis connection: 0.0.0.0:9001 bayernluft.0 2024-12-27 17:09:16.037 info terminating bayernluft.0 2024-12-27 17:09:15.542 info Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason bayernluft.0 2024-12-27 17:09:15.541 info terminating bayernluft.0 2024-12-27 17:09:15.535 info Got terminate signal TERMINATE_YOURSELF bayernluft.0 2024-12-27 17:09:09.063 info starting. Version 2.0.0-alpha.0 (non-npm: boriswerner/ioBroker.bayernluft#7b7a3e71591d1b2e75fa9e21cc93e4554d226337) in /opt/iobroker/node_modules/iobroker.bayernluft, node: v20.18.1, js-controller: 7.0.3 -
Ich hab über die Feiertage noch die anderen Kommandos korrigiert und einen Pull Request gestellt, setSpeed und alles, was bisher da war, funktioniert bei mir nun auch ohne Probleme (setAuto kann ich nicht wirklich testen, da ich keine Feuchtesensoren im Gerät hab, gibt aber keinen Fehler).
In der Readme hab ich noch ein paar Ideen für mögliche Änderungen und Optimierungen reingeschrieben. Auch bietet die API jetzt noch ein paar mehr Möglichkeiten, die relevanten Stellen hab ich auch mal reinkopiert.
Für eine stable 2.0 Version wäre es natürlich schön, die Optimierungen gemacht zu haben, so funktioniert das aber schonmal (@mcm1957 wenn ich mich da mal ransetze, sollte ich dann lieber mit dem neuen Adapter Template / Create Adapter starten, damit man keine Altlasten mitschleppt? Sonderlich viel Logik ist ja in dem Adapter nicht und davon würde ich eh die Hälfte gerne wegschmeißen. Da ist es vielleicht einfacher bei einem aktuellen Stand bei 0 anzufangen... gibt das Probleme beim Merge?) -
@boriswerner sagte in Bayernlüfter und ioBroker:
setAuto kann ich nicht wirklich testen, da ich keine Feuchtesensoren im Gerät hab, gibt aber keinen Fehler
das teste ich dann, sobald er zum update aufscheint
-
DANKE für die Arbeit und den PR.
Gut dass du hier postest - hatte das Repo nochnicht auf watch und den PR daher nicht gesehen. Ich werd schaun dass ich in den nächsten Tagen eine neue Release rauslasse. -
Ich habe nun endlich ein wenig Zeit rausgepresst und den PR in eine Version 2.0.0 einfließen lassen. Diese Version ist ab sofort auf npm verfügbar. Installation bei aktiviertem Experten Modus via Katzensymbol und bei url
iobroker.bayernlufteingeben (siehe unten)Von einer direkten Installation von GitHub wird abgeraten.
Der Adapter kommt nach einem Review und allenfalls noch notwendiger Anpassungen dann ins LATEST.
Der zugehörige Diskussionsthread findet sich hier: https://forum.iobroker.net/topic/79277/test-adapter-bayernluft-2-0-x
@Homoran Bitte hier schließen um Zweigleisigkeit zu vermeiden.
