state in WindowRec (HM-TC-IT-WM-W-EU)

Begonnen von DerFrickler, 22 Januar 2016, 15:45:30

Vorheriges Thema - Nächstes Thema

DerFrickler

Hallo zusammen,

ich werfe die Frage auch mal hier ins Forum, da es sich ja sicherlich nicht um ein Frontend spezifisches Problem handelt, auch wenn das Frontend ausschlaggebend für diese Problematik war.

Folgendes: Ich habe ein peering zwischen einem Wandthermostat (HM-TC-IT-WM-W-EU) und einem Fenstersensor (HM-SEC-RHS). Das klappt auch alles wunderbar, lediglich wäre es für die Nutzung des smartVisu Frontends sinnvoll das Reading state im WindowRec Kanal des Wandthermostats zu nutzen, dieses hat aber durchgehend den Wert unknown. An Stelle des Reading state gibt es da noch das Reading trig_window.sensor.Wohnkeller welches den Fensterstatus auch korrekt wiedergibt.

Für den Fall dass ich aber den zweiten Fenstergriff auch mit einem Fenstersensor ausstatten möchte, wäre es sinnvoll die Stati beider Sensoren (davon ausgehend dass der zweite auch ein Status Reading wie trig_window.sensor.Wohnkeller generieren wird) miteinander zu kombinieren. Ich hatte ursprünglich gehofft das dieses automatisch auf dem Reading State erfolgt, leider aber nicht.

Hat diesbezüglich jemand von Euch eine Idee wie man sowas ohne Notify mit Zurückschreiben des Readings state gestalten kann?

Gruß!

Hier der ursprüngliche Beitrag unter der Rubrik Fronten:
http://forum.fhem.de/index.php/topic,36129.msg396233.html#msg396233

kleinerDrache

schau dir mal Struct an ;-) damit deine Fensterkontakte zusammenfassen und den state vom Struct in Smartvisu nutzen
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

DerFrickler

Da es keine weiteren Vorschläge gibt werde ich mich mal damit beschäftigen. Lieber wäre mir eine Lösung die ich direkt in den WindowRec Kanal einbinden könnte, ähnlich dem stateFormat.

Gruß!

frank

Zitat von: DerFrickler am 28 Januar 2016, 13:14:41
Da es keine weiteren Vorschläge gibt werde ich mich mal damit beschäftigen. Lieber wäre mir eine Lösung die ich direkt in den WindowRec Kanal einbinden könnte, ähnlich dem stateFormat.

Gruß!
das kannst du doch mit stateformat tun.
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

DerFrickler

das mit dem state klappt jetzt wunderbar, nur musste ich feststellen das fhem nicht das Reading state, sondern das Internal STATE an smartVISU übergibt. Das voreingestellte stateFormat wollte ich jetzt nicht ändern, wer weiss was wofür das gut ist und was man sich damit zerschiessen könnte.

Gruß!

awe

Moin,
ich habe auch das Problem, dass der state im _WindowRec immer auf unknown steht (wobei die trigLast und trug_<FensterKontakt> schon den richtigen Wert liefern).
Wie hast Du das mit dem state = unknown denn nun gelöst? Das Stichwort "stateFormat" sagt mir leider nichts.
Danke & Gruß,
Axel

martinp876

attr TC_WINREC stateFormat last:trigLast

Peter aus Calw

Hallo zusammen,
der Versuch mit :
attr TC_WINREC stateFormat last:trigLast
ändert den Zustand in window_rec:
state          unknown

gar nicht, was kann man hier noch tun ?
Grüße von Peter

Otto123

Hallo Peter,

soll auch nicht, es soll das Internal STATE ändern. Du schaust aufs Reading state.
Beispiel:
Internals:
   DEF        32266703
   FUUID      5c5f2950-f33f-520c-cde3-b2a412aed377ebfc
   NAME       SensorR1_WindowsRec
   NOTIFYDEV  global
   NR         38
   NTFY_ORDER 50-SensorR1_WindowsRec
   STATE      last:FensterAZL:open
   TYPE       CUL_HM
   chanNo     03
   device     SensorR1
   READINGS:
     2017-07-24 00:02:47   R-sign          off
     2020-10-24 00:21:11   RegL_01.         00:00 08:00
     2020-10-24 00:21:11   state           unpeered
     2018-10-24 21:56:25   trigLast        FensterAZL:open
     2018-10-24 21:56:25   trig_FensterAZL Open_3
   helper:
     peerFriend peerSens,peerVirt
     peerIDsRaw ,00000000
     peerOpt    3:thermostat,7p:thermostat
     regLst     1,3p,7p
     tmplChg    0
     cmds:
       TmplKey    :1603483835.21189:1603483835.24023
       TmplTs     1603483835.24023
       cmdKey     :1:0:0::00AD:03
       TmplCmds:
       cmdList:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         eventL:-peer- -cond-
         eventS:-peer- -cond-
         getConfig:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         inhibit:[on|off]
         peerBulk:-peer1,peer2,...- [set|unset]
         press:[long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         sign:[on|off]
         tplDel:tmplt
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   model      HM-TC-IT-WM-W-EU
   peerIDs    00000000,
   room       Arbeitszimmer
   stateFormat last:trigLast


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