HM-PB-2-WM55-2 per FHEM Status setzen

Begonnen von timtom, 09 November 2016, 18:20:55

Vorheriges Thema - Nächstes Thema

timtom

Hallo zusammen,

ich habe mir einen HM-PB-2-WM55-2 als Homestatus Taster eingerichtet und mittels Wiki mit einem virtuellem Aktor verbunden. Je nach Tastendruck wird über DOIF eine LightScene angesteuert. Soweit so gut.

Jetzt möchte ich neben dem Taster, den Status auch overrulen können. Dafür nutze ich das "Homestatus-Element" von TabletUI mit device=hm_wandtaster. Damit möchte ich sowohl den aktuellen Status anzeigen lassen, wie auch ändern können. Da ich anscheinend mit Tablet UI nur ein Gerät einbinden kann, kann ich nicht den Wandtaster auslegen und die virtuellen Buttons schalten -> sondern nur den HM-PB-2-WM55-2. Jetzt verzweifel ich jedoch daran, den Status entsprechend zu setzten. Mit welchem fhem-Befehl auf das Device bekomme ich das hin? Also sowas wie "set hm_wandtaster hm_WandtasterHoch Short" nur in richtig.

Natürlich könnte ich noch einen zusätzlichen Dummy einführen, aber ich möchte gerne unnötigen Ballast vermeiden.

Beste Grüße

timtom

Hallo, ich komme einfach nicht weiter. Kann man wirklich nicht den Status des HM-PB-2-WM55-2 manuell setzten. TabletUI kann ja leider nur Kommandos "set HM-PB-2-WM55-2 ..." absetzten :(

frank

ein sensor/button hat, in deinem sinn, keinen status. er detektiert tastendrücke.
einem temperatursensor kannst du auch nicht sagen, dass er jetzt 18.7 grad messen soll.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

aber mit setstate geht das prinzipiell. Ob das wirklich Sinn macht?
http://fhem.de/commandref_DE.html#setstate

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

es sollen ja nur set befehle funktionieren.
da bleibt wohl nur der dummy.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

timtom

Danke. Hat jetzt mit setstate geklappt. ;)

Warum es keinen Sinn machen sollte den Status eines Tasters zu verändern ist mir aber immer noch nicht klar. Streng genommen ist das nämlich ja auch nicht der aktuelle Status, sondern der, der letzten Aktion. Dann wäre das damit eigentlich ein integrierter Dummy?

frank

ZitatWarum es keinen Sinn machen sollte den Status eines Tasters zu verändern ist mir aber immer noch nicht klar.
von sinn oder unsinn habe ich überhaupt nicht gesprochen.

der eigentliche taster lässt sich nun mal nur manuell bedienen, nicht remote. der status des sensors, der den taster überwacht, ist eigentlich immer im überwachungsstatus und sendet ggf trigger, dass er etwas erkannt hat. der letzte trigger wird ja sowieso in diversen readings gespeichert.

mit setstate manipulierst du ja nur das fhem state reading, aber keinen status des gerätes. jede protokoll mitteilung (missingAck, cmds_done, ...) wird dir das reading wieder überschreiben.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

marvin78

Stell dir, wie oben schon erwähnt, den Schalter als Sensor vor, dann ist es ggf. verständlicher. Genau das ist er nämlich, ein Sensor, der Daten sendet.

Otto123

Genau deshalb würde ich nicht auf die Idee kommen, einem Sensor zu sagen Du liegst falsch, es ist anders.
Ist so wie wenn man ein Thermometer hat und dort ein Schild auf die Anzeige klebt mit 21° ... Aber generell kann man auch das tun.
:o

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

timtom

Zitat von: frank am 10 November 2016, 12:23:16
von sinn oder unsinn habe ich überhaupt nicht gesprochen.

der eigentliche taster lässt sich nun mal nur manuell bedienen, nicht remote. der status des sensors, der den taster überwacht, ist eigentlich immer im überwachungsstatus und sendet ggf trigger, dass er etwas erkannt hat. der letzte trigger wird ja sowieso in diversen readings gespeichert.

mit setstate manipulierst du ja nur das fhem state reading, aber keinen status des gerätes. jede protokoll mitteilung (missingAck, cmds_done, ...) wird dir das reading wieder überschreiben.
Ah ok. Danke. Ich verstehe. Ich habe ja ein DOIF, das durch den (Homestatus) Taster getriggert wird, z.B. Heizung an/aus. Mittels Tablet UI und setstate "missbrauche" ich den Taster dafür, das DOIF anzustoßen.

Jetzt hast du natürlich Recht, dass mit setstate das Reading manipuliert wird und möglicherweise überschrieben wird, z.B. CMDs_pending. Dann würde die UI natürlich auch etwas falsches anzeigen. Dann muss ich heute Abend mal weiter gucken.

Otto123

Zitat von: timtom am 10 November 2016, 12:52:55
Ich habe ja ein DOIF, das durch den (Homestatus) Taster getriggert wird, z.B. Heizung an/aus. Mittels Tablet UI und setstate "missbrauche" ich den Taster dafür, das DOIF anzustoßen.
Genau das dürfte aber nicht gehen - Zitat:
ZitatDer Befehl setzt den STATE Eintrag des Gerätes direkt, ohne Ereignisse zu generieren oder ein Signal an das Gerät zu senden

Der Taster an der Wand hat doch gar keinen Status!? Der ist gedrückt oder nicht, wenn er an der Wand hängt ohne das einer drückt - dann eher nicht.  ;D

Der Tastendruck wird zu einem Status verarbeitet, das muss doch der Dreh und Angelpunkt sein und nicht der Taster an der Wand? Der Taster könnte eine Anzeige LED haben die durch den Status gesetzt wird, das wäre dann wieder etwas, was man beeinflussen und abfragen kann. Das wäre auch ein Aktor  und kein Sensor.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

timtom

Ok, ich verstehe. Dann ist meine Abbildung wahrscheinlich auch nicht so ganz richtig.

1. "fl_Wandtaster" HM-PB-2-WM55-2 mit channel_01=fl_WandtasterRunter und channel_02=fl_WandtasterHoch
2. "Heizungsmodus" Dummy mit Status Sommer oder Winter
3. "ZuhauseStatusLS" LightScene mit Scenen, z.B. SummerHome, WinterAbsent, SommerAbsent
4. di_WandtasterAktion DOIF, um mit dem Wandtaster die "ZuhauseStatusLS" zu triggern
([Heizungsmodus:state] eq "Sommer" and [fl_Wandtaster:state] eq "fl_WandtasterRunter Short")
  (set ZuhauseStatusLS scene SummerAbsent) DOELSEIF
([Heizungsmodus:state] eq "Winter" and [fl_Wandtaster:state] eq "fl_WandtasterRunter Short")
  (set ZuhauseStatusLS scene WinterAbsent) DOELSEIF
...


Das funktioniert ja soweit. Jetzt möchte ich jedoch die ZuhauseStatusLS auch über eine UI triggern.
Eine Möglichkeit wäre...
...einen neuen Dummy "ZuhauseStatus" mit Status Home, Absent...
...das "di_WandtasterAktion" DOIF so anpassen, dass der neue "ZuhauseStatus" Dummy entsprechend gesetzt wird
...ein neues "di_ZuhauseStatusLS" DOIF, um die entsprechende "ZuhauseStatusLS" LightScene in Abhängigkeit von den Dummies "Heizungsmodus" und "ZuhauseStatus" auszuwählen.
(...mit der UI müsste ich dann nur den euen Dummy "ZuhauseStatus" setzen)

Oder geht das irgendwie einfacher?

Otto123

Hi,

ich glaube, nachdem ich es ein paar gelesen und durchdacht habe, du hast ein Problem im Ansatz. Also nicht in den Tools/Umsetzung sondern in der Logik.
Es ist auch zugegeben nicht so leicht, ich habe mir das auch mal für mich durchdacht und aufgeschrieben. Vielleicht hilft Dir das.

Du siehst an Deiner eigenen Beschreibung eigentlich genau das Problem, bei jedem neuen Kriterium (Sensor) musst Du Deine Logik neu programmieren. Mein Ansatz mag etwas komplex erscheinen, aber jetzt definiere ich ein neues Kriterium, modifiziere eine Structure und fertig.
Ich kann mit meinem Konstrukt einfach eine neue Person hinzufügen oder zu einer Person ein neues Anwesenheitskriterium. Egal ob Schalter oder Erkennung von einem Device.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

timtom

Zitat von: Otto123 am 10 November 2016, 22:50:55
Hi,

ich glaube, nachdem ich es ein paar gelesen und durchdacht habe, du hast ein Problem im Ansatz. Also nicht in den Tools/Umsetzung sondern in der Logik.
Es ist auch zugegeben nicht so leicht, ich habe mir das auch mal für mich durchdacht und aufgeschrieben. Vielleicht hilft Dir das.

Du siehst an Deiner eigenen Beschreibung eigentlich genau das Problem, bei jedem neuen Kriterium (Sensor) musst Du Deine Logik neu programmieren. Mein Ansatz mag etwas komplex erscheinen, aber jetzt definiere ich ein neues Kriterium, modifiziere eine Structure und fertig.
Ich kann mit meinem Konstrukt einfach eine neue Person hinzufügen oder zu einer Person ein neues Anwesenheitskriterium. Egal ob Schalter oder Erkennung von einem Device.

Gruß Otto
Hallo Otto,

danke für den Link. Genau dein Beispiel hatte ich bisher implementiert. Ich hatte jedoch Ping anstelle von MAC genommen. Da mir die Erkennung jedoch zu fehleranfällig war (z.B. Handy im Standby), habe ich die Elemente gelöscht und bin auf den Taster gegangen.
Ich überlege jedoch gerade aus Komfortgründen das alles wieder einzuführen und den Taster zu ergänzen. Bein den Handy-DOIF würde ich dann ein weit von 5 Minuten(?) einbauen, um die Toleranz etwas zu erhöhen.

Otto123

Ich habe ein wait von 300 -> 5 min drin bei der Structure von den Geräten zur Erkennung Person da oder weg.
Ich erkenne die Handys mit Bluetooth und Wlan. BT ist absolut zuverlässig, ich brauche aber zwei Detektoren im Haus. Wlan hatte ich zuerst und habe es gelassen.
Zusätzlich habe ich meinen kleinen Enkel und Gäste als virtuellen Knopf.
Damit triggere ich Ereignisse Personenbezogen und auf die Gesamtheit -> mindestens einer ist da.

Aber ob Du das mit Geräte Erkennung oder mehreren "Knöpfen/Sensoren" machst ist egal.

Gruß
Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz