rename von Channel in VCCU funktionert nicht fürs anlegen eines virtuellen Fenst

Begonnen von Ruggy, 26 Januar 2023, 17:52:45

Vorheriges Thema - Nächstes Thema

Ruggy

Stimmt, im roten Kasten steht ausdrücklich, dass es mit den virtueller Fensterkontakt und virtueller Temperaturfühler über die VCCU nciht funktioniert.
Bei mir haben zumindest zwei virt. Fensterkontakte trotzdem funktioniert. Evlt. war dies aber auch Zufall und ich möchte es jetzt so umstellen, wie es sich gehört.

Habe ich es jetzt so richtig verstanden, dass z.B. BAD_virt_Sensoren das "Hauptdevice" ist in welchen ich dann virtual 1 (z.B. für Fenster) und virtual 2 (z.B. für Temperatursensor) anlege?


Also sollte ich beim Anlegen jetzt so vorgehen?

virt. Fenstersensor:

define BAD_virt_Sensoren CUL_HM 123456
attr BAD_virt_Sensoren model VIRTUAL
set BAD_virt_Sensoren virtual 1
rename BAD_virt_Sensoren_Btn1 BAD_virt_Fenster
attr BAD_virt_Fenster webCmd postEvent open:postEvent closed
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single set
set BAD_HEIZUNG_Window_Rec regSet winOpnTemp 5 BAD_virt_Fenster
set BAD_HEIZUNG_Clima regSet winOpnMode off



Benötige ich folgendes oder kann ich es weg lassen. Im Wiki ist es nicht erwähnt.
Ich hatte es mir aber damals so notiert. oder muss ich hier VCCU anstatt HmUART schreiben?
attr BAD_virt_Sensoren IODev HmUART


Danach Einrichtung virt Temperatursensor:

set BAD_virt_Sensoren virtual 2
rename BAD_virt_Sensoren_Btn2 BAD_virt_Temperatur
set BAD_virt_Temperatur peerChan 0 BAD_HEIZUNG_Weather single set



Vorher müsste ich aber wahrscheinlich das bisherige löschen bzw. rückgängig machen.
Bei den Channels in VCCU in den jeweiligen Channel gehen und unten device löschen?

Wie kann ich den peerChan rückgängig machen?
Muss ich das als erstes Machen?

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 11:06:18
Wie kann ich den peerChan rückgängig machen?
Muss ich das als erstes Machen?
Korrekt, das solltest du als erstes tun.

ZitatHabe ich es jetzt so richtig verstanden, dass z.B. BAD_virt_Sensoren das "Hauptdevice" ist in welchen ich dann virtual 1 (z.B. für Fenster) und virtual 2 (z.B. für Temperatursensor) anlege?
Das kann man so machen (läuft bei mir so seit Jahren), franks Empfehlung ist etwas weitergehend.

ZitatAlso sollte ich beim Anlegen jetzt so vorgehen?

virt. Fenstersensor:

define BAD_virt_Sensoren CUL_HM 123456
attr BAD_virt_Sensoren model VIRTUAL
set BAD_virt_Sensoren virtual 1
rename BAD_virt_Sensoren_Btn1 BAD_virt_Fenster
attr BAD_virt_Fenster webCmd postEvent open:postEvent closed
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single set
set BAD_HEIZUNG_Window_Rec regSet winOpnTemp 5 BAD_virt_Fenster
set BAD_HEIZUNG_Clima regSet winOpnMode off

Du kannst auch gleich 2 virtuelle Kanäle anlegen, wenn du die am Ende brauchst/haben willst, aber sollst müßte es passen.

ZitatBenötige ich folgendes oder kann ich es weg lassen. Im Wiki ist es nicht erwähnt.
Ich hatte es mir aber damals so notiert. oder muss ich hier VCCU anstatt HmUART schreiben?
attr BAD_virt_Sensoren IODev HmUART
Da du eine VCCU hast, solltest du stattdessen m.E. mit IOGrp arbeiten (und damit auf die VCCU zeigen).

Ansonsten paßt m.E. die Richtung.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Zitat von: frank am 27 Januar 2023, 10:44:28
ist doch eigentlich ganz einfach.  :)

wer folgende "regel" beherzigt, wird dauerhaft keine probleme haben:
1. jedes reale non-homematic-gerät bekommt in fhem ein eigenes virtuelles homematic hauptdevice mit einem channel.

Ich glaube so langsam lichtet sich der Horizont. Aber ein paar Wölkchen sind schon noch da  ;)

Mit dem Hinweis 1. ist jetzt wieder ein kleines Wölchken mehr aufgetaucht.
Jedes reale Homematic Gerät (das ich in der Hand halten kann ;-) bekommt ein virtuelles Hauptdevice.
Aber wieso nur mit einen Channel? Wohin gehört der Channel 2. Ich habe ja zwei Geräte, welche ich mit den Homematic Gerät verbinden will (Temperatursensor und Fenstersensor)?

Zitat von: Beta-User am 27 Januar 2023, 11:35:35
Ansonsten paßt m.E. die Richtung.

Das freut mich. Hat meine grauen Gehirnzellen in Schwung gebracht.


Das Peering müsste ich so aufheben können?
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single unset

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 11:55:19
Das Peering müsste ich so aufheben können?
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single unset
Sowas steht doch in der Doku?

ZitatJedes reale Homematic Gerät (das ich in der Hand halten kann ;-) bekommt ein virtuelles Hauptdevice.
Das ist m.E. eine falsche Schlussfolgerung! Einen HM-Fenstersensor kann man doch auch mit 2 oder 3 RTs bzw. WTs peeren! Das geht mit einem virtualisierten Fenstersensor doch genauso! dto. für einen Temp-Sensor (da sind sich frank und ich uneinig, ob man dafür einen extra Hauptkanal "verschwenden" muss).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat von: Beta-User am 27 Januar 2023, 10:22:16
Der "rote Kasten" war afaik schon immer im Detail nicht 100% korrekt -
Danke, der ist von mir :) aber seinerzeit geschrieben aus einer Kombination von eigenen Erfahrungen und Erfahrungen in verschiedenen Threads hier im Forum.
Frank hat es kürzer und knackiger formuliert: da könnte ich jetzt noch den Umkehrschluss anfügen: Die virtuellen Kanäle der VCCU taugen eigentlich nur als Peer Endpunkte für Homematic Fernbedienungen, die selbst keinen anderen echten Peer haben, damit diese "grünes Licht" bei der Betätigung erzeugen. Richtig?

Zitat von: Ruggy am 27 Januar 2023, 11:06:18
Bei mir haben zumindest zwei virt. Fensterkontakte trotzdem funktioniert. Evlt. war dies aber auch Zufall und ich möchte es jetzt so umstellen, wie es sich gehört.
Wie hat mein Kollege mal gesagt: Es besteht kein Rechtsanspruch auf die Beibehaltung von Fehlern  ;D ;D ;D
Oder allgemeiner: Kann gehen - muss aber nicht (immer).
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

Beta-User

Zitat von: Otto123 am 27 Januar 2023, 12:52:17
Richtig?
...das ist ein bißchen wie bei den diversen Atommodellen: Für den Einstieg ist es "richtig", im Detail komplett falsch ;D ...

Anders gesagt: Ich stehe 100% hinter der dringenden Empfehlung an alle, die keine Experten sind, die Kanäle der VCCU nur zu Zwecken des "grünen Lichts" zu verwenden. (Inhaltlich) nichts wesentlich anderes war übrigens der dringlichen Empfehlung in meinem ersten Beitrag hier zu entnehmen...

Alles andere führt nur in irgendwelche Untiefen aus firmware-Versionen, Hardware-Varianten und CUL_HM-Versions-Ständen (ggf. noch gemixt mit IO-Spezifika...)

PS: Ich habe durchaus Fälle hier, bei denen zur Frage der Öffnung eines virtuellen Kontakts mehrere reale Geräte ausgewertet werden (falls überhaut "Heizzeit" ist; ähnlich für's Schließen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Werde mir später noch anschauen, wie ich die bisherigen Geräte angelegt habe. Kann sein, dass hier dann auch was nicht stimmt.
Vor allem habe ich hier bisher die Fenster noch gar nicht eingebunden. Wollte mich erst mal an die Räume mit einem Fenster und einen Sensor wagen.

Hierzu noch eine Frage, weil ich in einem Raum drei reale_Thermostate habe, einen Temperatursensor (= TS) und zwei Fenster (Fenster 1 = F1, Fenster 2 = F2) , welche ich mit einbeziehen möchte.
Ich wage es jetzt mal zu schreiben, wie ich es machen würde:


- Zu jedem realen Thermostat (T1, T2, T3) ein virtuelles Hauptdevice anlegen (vT1, vT2, vT3)
- In jeden virtuellen Hauptdevice jeweils zwei Channel (z.B. C1 = Temperatur, C2 = Fenster)



dann peere ich:

Temperatursensor:
vT1-C1 mit TS
vT2-C1 mit TS
vT3-C1 mit TS

Fenster:
vT1-C2 mit F1
vT1-C2 mit F2
vT2-C2 mit F1
vT2-C2 mit F2
vT3-C2 mit F1
vT3-C2 mit F2

Kann man das so machen und funktioniert dann auch?
Sorry der Nachfrage, aber ich möchte in meinen FHEM nicht noch mehr durcheinander bringen, als es wahrscheinlich schon ist.

frank

ich würde 2x virtuelle fensterkontakte und 1x virtuellen temperaturfühler definieren, mit jeweils einem channel.
virtuelle homematic-devices braucht man nur für die nicht-homematic-geräte!!
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

Beta-User

(auch, frank war schneller) M.E. viel zu kompliziert:

Ein virtueller Kanal für den TS reicht, an den werden alle RT's gepeert.

Bei mir gäbe es dann auch nur einen virtuellen F, der den konsolidierten Zustand von F1 und F2 enthält. Ein entsprechendes notify steht im Wiki.

Bei mir ist das übrigens für alle Fensterkontakte (hausweit!) ein einziges notify, was wie zusammengehört, steht in Attributen, und geöffnet wird auch erst, wenn eine kurze (einstellbare) Zeit vergangen ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Werde es mal versuchen. Weiß jetzt noch nicht genau nach welcher Methode.

Die Methode mit notify hört sich auch recht komfortabel an.
Hierbei kann ich persönlich mit dem notify aber wieder einigies durcheinander bringen ;-)

Macht es dir was aus das notify mit den (hausweiten) Fensterkontakten zu zeigen?
Habe für jedes Fenster ein notify.

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 14:17:19
Macht es dir was aus das notify mit den (hausweiten) Fensterkontakten zu zeigen?
Nö, ist immer mal wieder aktualisiert worden, hier (vermutlich) die aktuellste Fassung; Code ist im ersten Post:
https://forum.fhem.de/index.php/topic,97430.msg1223653.html#msg1223653

Zitat von: Ruggy am 27 Januar 2023, 14:17:19
Habe für jedes Fenster ein notify.
Am Ende ist es halt wichtig, dass du selbst überblicken kannst, warum was passiert. Ich finde weniger Geräte - ggf. in Verbindung mit besserem/universellerem Code - halt übersichtlicher, darum "will" ich auch nicht mehr Stammdevices anlegen wie "nötig"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy


Beta-User

...der Vollständigkeit halber: Auch die Übertragung der gemessenen Temperaturen an die virtuellen Kanäle erfolgt "hausweit" mit nur einem notify. Das sieht so aus:

define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.*  {\
my %tsensorsmap = (\
  Raumfuehler_Buero => 'Fake_Fenster_Buero_Temp',\
  Raumfuehler_Kind1 => 'Fake_Fenster_Kind1_Temp',\
[...]
  Temperatur_Schlafzimmer => 'Fake_Fenster_SZ_Temp',\
  Raumfuehler_Wohnzimmer => 'Fake_Tuere_WZ_Temp',\
  );;\
  return if !defined $tsensorsmap{$NAME};;\
  if( $EVTPART1 eq '0.000' ) {\
    fhem("msg $NAME scheint ausgefallen zu sein (readingsWatcher)");;\
    return CommandDeleteReading(undef, "$tsensorsmap{$NAME} temperature");;\
  }\
  return CommandSet(undef, "$tsensorsmap{$NAME} virtTemp $EVTPART1")\
}

Vorbedingungen:
Falls ein Sensor zu lange keine Infos liefert, schlägt im Hintergrund ein readingsWatcher zu und stellt eine eher ungewöhnliche "0" ein.
"msg" funktioniert nur, wenn msgConfig entsprechend vorbereitet ist.

(Ich gebe zu, dass ich heute die Benennungen der Devices anders strukturieren würde...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Beim folgenden Befehl kommt nachfolgende Meldung:

set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_Window_Rec single set


please enter peer

Habe noch das virtuelle Hauptdevice "SCHLAFZIMMER_virt_Sensoren" mit folgenden Attribut ergänzg; funktionierte aber auch nicht.
attr SCHLAFZIMMER_virt_Sensoren IOgrp VCCU

Habe mal versucht hmPairForSec mit dem VCCU auszuführen und auch von HmUART aus.
Beide mal der selbe Fehler.

Bei den Temperatursensor und Fenstersensor handelt es sich um Xiaomi. Aber das dürfte hier doch noch keine Rolle spielen.


List vom virtuellen Schlafzimmer Hauptdevice:
Internals:
   DEF        62FAB4
   FUUID      63d3fe31-f33f-194f-9f82-a89000fa0ea91192
   IODev      HmUART
   NAME       SCHLAFZIMMER_virt_Sensoren
   NR         763
   NTFY_ORDER 48-SCHLAFZIMMER_virt_Sensoren
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   channel_01 SCHLAFZIMMER_virt_Fenster
   channel_02 SCHLAFZIMMER_virt_Temperatur
   disableNotifyFn 1
   READINGS:
     2023-01-27 17:55:34   IODev           HmUART
     2023-01-27 17:41:07   RegL_00.       
     2023-01-27 17:39:22   cfgState        updating
     2023-01-27 17:39:44   commState       CMDs_done_Errors:1
     2023-01-27 17:39:44   state           RESPONSE TIMEOUT:RegisterRead
   helper:
     HM_CMDNR   37
     mId        FFF1
     peerFriend -
     peerOpt    -:virtual
     regLst     0
     rxType     1
     cmds:
       TmplKey    :no:1674837860.84256
       TmplTs     1674837860.84256
       cmdKey     0:1:1::SCHLAFZIMMER_virt_Sensoren:FFF1:00:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       vccu       VCCU
       prefIO:
     mRssi:
       mNo       
       io:
         HmUART:
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   model      VIRTUAL
   room       Schlafzimmer
   subType    virtual
   webCmd     virtual

Ruggy

Sorry, der Fehler sitzt vorm Computer

es war ein "_" zuviel im Namen SCHLAFZIMMER_HEIZUNG_Window_Rec

Falsche Schreibweise:
set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_Window_Rec single set

richtige Schreibweise:
set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_WindowRec single set