Bayernlüfter und ioBroker

[mcm1957]

@boriswerner said in Bayernlüfter und ioBroker:

Hi, ich hab meinen Bayernlüfter frisch bekommen und hab mir den Adapter mal angesehen.
Ich hab einen eigenen Fork auf github: https://github.com/boriswerner/ioBroker.bayernluft
Es gibt zwar immer noch die Warnungen bei der Adapterinstallation, aber die grundlegenden Funktionen laufen bei mir (kommt bestimmt aber auch auf das Alter des Geräts und die Firmware an).

Der Connect läuft jetzt wieder (die URL hat sich geändert), die Typen-Warnungen sind weg und auch die Funktionen powerOn, powerOff, buttonPower funktionieren.
setSpeed läuft irgendwie noch nicht und bitte nicht den button setAuto drücken, der startet irgendwie einen loop (kann im log anhand der debug-Nachrichten erkannt werden, daher bitte das loglevel auf debug setzen!)

Bitte aufpassen, ich hab auch in der export.txt einen Namen angepasst, da es den antiFreeze und AntiFreeze gab. Das sind jetzt speed_antiFreeze und AntiFreeze (letzteres ist ein Status on/off). Daher muss auch die Datei neu auf den Lüfter transferiert werden (siehe Readme in meinem Fork, da ist das Template angepasst)

Alles as-is ohne Gewähr und ich hab leider seit Ewigkeiten nicht mehr an einem Adapter gebaut, daher kenne ich die aktuellen Best Practices leider nicht und hab nicht wirklich Zeit mich da einzuarbeiten. Momentan committe ich auch direkt über github Web. Ich würde mich erstmal rein auf die Funktion beschränken.

@negalein was willst du denn insbesondere mit dem Adapter machen? Brauchst du spezielle Funktionen oder Infos? Speed würde ich auf jeden Fall noch machen, kann aber nicht sagen, wann ich dazu komme.
Festliche Grüße
Boris

Wenn du Fehler gefunden / behoben hast, dann erstell doch bitte einen PR. Das geht auch wenn du nur via GitHub Web was ausbesserst.

Bezüglich Infrastruktur (Versioniereung etc) kann ich gerne mithelffen / durchführen damit dass in eine normale Release kommt. Ich hab nur keine Zeit den Adapetr zu debuggen und mangels passender Hardware macht es auch nur bedingt sinn.

Freu mich von dir zu hören.
Gern auch auf den Development Kanälen (Telegramm bzw. Discord - invites auf www.iobroker.dev)

mcm1957

[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