Mehrere Readings zusammenfassen

[pula]

Hallo,

ich hab hier mal eine etwas Anfängerfrage
Ich hab hier Fenster mit reed-Kontakten, die jeweils für offen oder gekippt Signal geben.
Um die abzufragen, hab ich mir einen Sketch für einen Aruduino zusammengeklempnert, der die stati dann per mqtt an fhem schickt.
Daraus möchte ich gerne dann für jedes Fenster einen Status Geschlossen/Gekippt/Offen ableiten.
Ich kenne verschiedene Möglichkeiten, zu realisieren, daß aus mehreren Readings ein einzelnes generiert wird (zb ein notify, das ein reading setzt oder auch stateformat).
Allerdings bin ich mir nicht sicher, was am elegantesten wäre. Das erzeugte Reading soll natürlich nicht nur angezeigt werden, sondern auch ausgewertet werden können (zb: fahre Rolladen nicht herunter, wenn Fenster offen)
Wie würdet ihr das machen? (Also das Schema wäre zb wenn der offen-sensor opened ist, soll das Fenster in einem Reading offen anzeigen).
Cheers,
Pula

[rabehd]

Das passt für mich nicht.
Du willst Readings zusammenfassen, schreibst aber

für jedes Fenster einen Status ... ableiten

Oft hilft da ein List.

[marvin78]

Ich habe auch gedacht: Irgendwas fehlt hier, oder ist missverständlich. Nicht nur, dass die Mehrzahl von Status Status (langes u) ist (sorry, da kann ich nicht anders).

[rudolfkoenig]

ich hab hier mal eine etwas Anfängerfrage

Stimmt, ist eine Anfaengerfrage, und gehoert deswegen ins Anfaengerbereich des Forums.
Die Loesung ist vmtl ein userReading: https://fhem.de/commandref_modular.html#userReadings

[pula]

Sorry, irgendwie hab ich mich scheinbar missverständlich ausgedrückt. Wollte nur wissen, wie ihr das machen würdet, weil Lösungen gäbe es da eine Menge
Userreading ist auch eine Möglichkeit. Da der Chef das vorschlägt, werde ich es wahrscheinlich auch so machen.
Nur noch der Vollständigkeit halber ein Schema, um das Ganze hoffentlich verständlicher zu machen.
Reading offen: opened, Reading gekippt: closed --> erzeugtes Reading: Offen
Reading offen: closed, Reading gekippt: closed --> erzeugtes Reading: Geschlossen
Reading offen: closed, Reading gekippt: opened --> erzeugtes Reading: Offen

Wie gesagt, das Problem ist an sich trivial. Die Frage war nur, wie es am elegantesten/effizientesten wäre, weil man möchte ja nicht immer mit Kanonen auf Spatzen schießen....

Cheers,
Pula

[Otto123]

Du willst alle Fenster einzeln in readings abbilden?
Du willst einen Status über alle Fenster? alle Fenster zu / ein Fenster auf
Wenn Du den Sketch selbst zusammenklöppelst, weißt Du ja was per mqtt gesendet wird. Vermutlich wäre ein json String zielführend.
Im MQTT2_DEVICE machst Du daraus einzelne Readings für jedes Fenster (json2nameValue / jsonmap)
Zusammenfassen in einen Fensterstatus kannst Du, wie schon erwähnt, einfach über ein userReadings.
Wenn kein json und alles verklausuliert in einer Nachricht kommen sollte (vielleicht bloß ne Bitmaske?) schreibst Du ein kurze Routine in der myUtils und machst es anstatt json2nameValue mit Übergabe in der readingList (mMn leicht anspruchsvoller als userReadings. )

Sorry war ich jetzt etwas langsam 

Gruß Otto

[pula]

Hi!
jedes Fenster einzeln. Und danke für die Antwort
klar wäre json auch eine Möglichkeit. Nur hab ich das Problem, daß ich erst nach der Verkabelung weiß, welcher Pin zu welchem Sensor führt (ältere Verkabelung und Kabel nicht ordentlich beschriftet). Da es sich um einen Uno handelt und der nicht per OTA upgedatet werden kann (zumindest hab ich noch keine Möglichkeit gefunden), hab ich das der Einfachheit halber so gebastelt und werte es innerhalb von fhem aus....
Wie gesagt, die Frage war eher nicht WIE es geht, sondern wie es am ELEGANTESTEN geht
Userreading scheint hier die Waffe der Wahl zu sein. Wieder mal...
Cheers,
Pula

[Otto123]

Aber ein list vom mqtt und was da ankommt wäre schon gut für Ideen

Ich fände es eleganter die ankommene Nachricht ($EVENT) gleich auszuwerten und Readings zurück zu geben.

[marvin78]

Und wenn du dabei bleiben möchtest, ist das eleganteste ein Userreading. Wobei das immer Ansichtssache bleiben wird.

[Beta-User]

Und wenn du dabei bleiben möchtest, ist das eleganteste ein Userreading. Wobei das immer Ansichtssache bleiben wird.

Elegant fände ich, wenn der Arduino die Auswertung gleich selbst machen würde...

Solange wir nicht wissen, wie die Daten eingehen, _kann_ das so sein, es klingt aber sehr danach, dass es "Spaß" ist, das über den userReadings-Weg auszuwerten: je nachdem, welcher der Werte für offen/gekippt jeweils pro Fenster zuerst kommt (oder doch bulk...?), braucht es einen anderen trigger (wenn man es sauber haben will...)

Ansonsten muss ich Otto recht geben: ohne nähere Info, was wann wie (aus welchem Anlass?) an Infos kommt, kann man eigentlich keine "gute" Antwort auf die Frage geben.

"Elegant" finde ich es, wenn man direkt auf einem Topic alles an (Änderungs-) Infos bekommt und dann nur die Readings im Ergebnis setzt, die man auch braucht; das wäre hier aber nur ein Status je Fenster...

[marvin78]

Elegant fände ich, wenn der Arduino die Auswertung gleich selbst machen würde...

Solange wir nicht wissen, wie die Daten eingehen, _kann_ das so sein, es klingt aber sehr danach, dass es "Spaß" ist, das über den userReadings-Weg auszuwerten: je nachdem, welcher der Werte für offen/gekippt jeweils pro Fenster zuerst kommt (oder doch bulk...?), braucht es einen anderen trigger (wenn man es sauber haben will...)

Ansonsten muss ich Otto recht geben: ohne nähere Info, was wann wie (aus welchem Anlass?) an Infos kommt, kann man eigentlich keine "gute" Antwort auf die Frage geben.

"Elegant" finde ich es, wenn man direkt auf einem Topic alles an (Änderungs-) Infos bekommt und dann nur die Readings im Ergebnis setzt, die man auch braucht; das wäre hier aber nur ein Status je Fenster...

Da du mich zitierst: Ich habe nicht umsonst geschrieben: "Und wenn du dabei blieben möchtest". Dann und nur dann, ist UserReading elegant.

[Beta-User]

OK, sorry, dass ich die Ironie überhört zu haben scheine...

userReadings und Eleganz - da sperrt sich bei mir was. Es ist eigentlich immer eine Krücke, wenn man diese Konstruktion braucht. Manchmal ist es halt nicht vermeidbar, wenn man nicht auf noch sperrigere Lösungen zurückgreifen will, aber das war es auch schon...
Na ja, lassen wir das .

[pula]

Naja, Eleganz scheint im Auge des Betrachters zu liegen
Die Readings sollten von dem Arduino eigentlich nicht als bulk kommen (es sei denn, er bootet neu - was ich natürlich noch bedenken sollte, danke für den Hinweis), sondern nur, wenn sich ein Sensor-Status ändert (aka ein Fenster wird irgendwie geöffnet/geschlossen).
Natürlich wäre es eleganter, das im Sketch zu lösen, aber ich tu mich leichter, das in fhem einzubauen, als jeden Pin zu testen und dann den Sketch neu aufzuspielen (Verkabelung von 6 Fenstern im Schaltschrank ist nicht gerade meine Vorstellung von Spaß). Und bei den paar Fenstern ist auch nicht gerade damit zu rechnen, daß hier hunderte Status-Änderungen pro Stunde eingehen.
Das Ganze ist eine Altlast. Vor 6 Jahren oder so, als ich mit fhem begonnen habe, hatte ich das ursprünglich mal mit HM wired gemacht. Mittlerweile haben die Dinger den Geist aufgegeben und ich bin nach und nach dabei, das auf Arduino umzubauen (hängen ja nur ein paar bereits umgebaute Taster und die Fenster-Sensoren dran).
Und ich möchte es halt so gut wie möglich machen
Cheers,
Pula