Bayernlüfter und ioBroker

Negalein

@boriswerner sagte in Bayernlüfter und ioBroker:

was willst du denn insbesondere mit dem Adapter machen?

Danke, cool dass du daran arbeitest.

Funktionen/Wünsche:

Werte auslesen (siehe WebIf)
Ein/Aus
Lüfterspeed

boriswerner

@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?)
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")

boriswerner

@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.

mcm1957

@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

mcm1957

@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.

Homoran

@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!

mcm1957

@homoran
wer wär da guter Ansprechpartner hier? Weisst du da was ?

Negalein

@mcm1957 sagte in Bayernlüfter und ioBroker:

Weisst du da was ?

@Dutchman hat DC

Negalein

@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

boriswerner

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?)

Negalein

@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 :)

mcm1957

@boriswerner

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.

mcm1957

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.bayernluft eingeben (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.

Community Forum

NEWS

Bayernlüfter und ioBroker

Support us

804

32.4k

81.6k

1.3m