TC emulieren

Begonnen von wkarl, 02 Januar 2014, 10:39:55

Vorheriges Thema - Nächstes Thema

wkarl

Hallo Martin,

am Ende der session ( CCC Conference in diesem Thread http://forum.fhem.de/index.php/topic,17959.0.html)wird erwähnt, dass die Kollegen einen TC emulieren können und damit einen VD kontrollieren. Diese Möglichkeit ist in diesem Forum schon ein paar mal diskutiert worden. Es fehlten aber immer die Informationen bzgl der Kommunikation TC-VD.
Ich vermute mal aus dem source code (https://www.homegear.eu/index.php/Downloads) der Kollegen könnte man diese Informationen gewinnen. Aktuell bin ich zwar mit der fhem-Lösung zufrieden wie sie funktioniert, aber wer weiß wofür man dies noch gebrauchen könnte.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

ich werden einmal suche gehen. Interessant ist es in jedem Fall. Falls es mit präzisem timing zu tun hat könnte es schwer werden. Aber erst einmal suchen....

Gruss Martin

frank

es gibt auch ein wiki von homegear. auf folgender seite wird das timing beschrieben:
https://www.homegear.eu/index.php/BidCoS_Packet_-_General_Information

ZitatTiming

The HomeMatic devices sleep most of the time to reduce battery consumption. Some devices (e. g. the HM-CC-VD) wake up at specific intervals waiting only for about 250 ms for an incoming packet. There is no packet sent when these devices wake up, so it is important to know, when this happens. Here is a C# code snippet of how the cycle length is being calculated:
int CalculateCycleLength(int DeviceAddress, int MessageCounter)
{
    const int MinimalCycleLength = 480;
    int Result = (((DeviceAddress << 8) | MessageCounter) * 1103515245 + 12345) >> 16;
    return (Result & 0xFF) + MinimalCycleLength;
}

The rusulting value is the sleeping time in units of 250 ms.
Synchronizing devices

Master and slave devices like a HM-CC-TC and a HM-CC-VD need to be synchronized in order for the master device to send its packet at the same moment the slave device wakes up and goes into Rx mode. The initial synchronization is done by pairing the devices. When the last pairing packet is received the normal duty cycle with its sleeping times starts. After that the slave device continuously synchronizes itself to the packets of the master device.
What happens when cyclic packets are not transmitted

When only one cyclic packet is not transmitted, the destination device waits for about 250 ms for an incoming packet and then goes to sleep again. After that the normal duty cycle continues.

When for whatever reason a master device (e. g. a HM-CC-TC) is not transmitting cyclic packets at all (maybe because the battery is empty), the destination (or slave) device (e. g. a HM-CC-VD) wakes up for six more duty cycles. With each duty cycle the device stays 500ms longer in Rx mode, so the durations in Rx mode for the six cycles are:

    250 ms
    750 ms
    1250 ms
    1750 ms
    2250 ms
    2750 ms

After that the duty cycle on the slave device does not continue. But the device wakes up for some minutes once in a while (once per hour?) and listens for incoming packets. This causes a very high battery usage.
What happens when a device is not reachable

When a slave device is not answering, the master device continues to send every duty cycle until the slave device answers again.

irgenwie habe ich dort noch kein inhaltsverzeichnis gefunden. deshalb bin ich bisher von link zu link gesurft. ansonsten "bidcos" in die suchmaske eingeben.

gruss frank
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

martinp876

hi,

interessante berechnung. Der wertebereich stimmt - aber die Kalkulation stimmt nicht mit der meines TC/VD überein.
Muss wohl mal im Code nachlesen

Gruss Martin

frank

hallo martin,

die funktion wird in "HomeMaticDevice.cpp" (rootverzeichnis des entpackten sourcecodes, downloadlink: http://homegear.eu/downloads/homegear_0.2.5-1.tar.gz) definiert, und in "HM-CC-TC.cpp" (verzeichnis "Devices") ein paar mal aufgerufen.

gruss frank
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

martinp876

Hi Frank,

danke, habe meinen Fehler erkannt. Muss auf long runden, dann stimmts

Gruss Martin

martinp876

Hi,

die Version 4558 sollte jetzt einen TC emulieren können - mit einschränkungen
Beispiel
define vtc CUL_HM 221133
set vtc virtual 1
rename vtc_Btn1 vtc1
set vtc1 peerChan 0 vd single set
set vtc1 valvePos 70
# anlernen am VD drücken


- Kommando valvePos hat ein virtual channel wenn er mit einem VD gepeert ist. Also darauf achten, dass nach dem peeren gespeichert wird, damit das Attribut peerIds gesichert ist.
- Die Einstellung startet aktuell nicht automatisch nach einem system restart
- mehrere VDs mit einem TC-simu-controll-channel habe ich nicht probiert
- Anlernen ist beim starten einmalig notwendig. Danach ist der VD bereit, sich auf das neue Zeitraster zu adaptieren
- ob sich der VD auch fängt, wenn man nicht "anlernt" habe ich nicht getesten, muss probiert werden
- bei den Einstellungen muss man natürlich Geduld haben, der VD kann nur alle ~2,5min beschrieben werden.

Gruss Martin

anierbeck

#7
Hi,

ich habe diesen Thread mit großem Interesse gelesen und gedacht, dass müsste sich doch auch für das Emulieren eines Fensterkontaktes nutzen lassen. Leider bekomme ich jetzt immer vom HM-CC-RT-DN ein NACK als Antwort auf ein set virtualKitchenDoor postEvent open.
Geht das überhaupt?
Kurzer abriss meines Scenarios, ich versuche einen MAX Fensterkontakt als Fensterkontakt für mein CC-RT-DN zu verwenden.
Was ich bisher erfolgreich umgesetzt habe ist das Absenken der Temperatur per manuellem modus sobald das Fenster geöffnet ist, ich finde aber die andere Lösung eleganter :D

Hier noch kurz meine Config:

define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor peerIDs 21BC8703,
attr virtualKitchenDoor room 1_HEIZUNG
attr virtualKitchenDoor webCmd press short:press long



Gruß, Achim

martinp876

Hallo Achim,

ja, sollte funktionieren.
der RT muss burst eingeschaltet haben (register burstRx im device).

Ich habe es noch etwas getunt.
Ich habe den Ablauf jetzt so gestaltet, dass beim postEvent der RT geweckt wird und dann der Kommand-stack abgearbeitet wird. Der "event" ist hinten angestellt (normal sollte die Queue eh leer sein).

Zu beachten ist beim RT (wie bei allen wakeup devices) msgRepeat - ein repeat kann ganz schon lange dauern, da es bis zum nächsten wakeup warten muss!

Die getunte Version ist jetzt in SVN und morgen im update

Gruss Martin

anierbeck

Hallo Martin,

ich habe es jetzt nochmal mit der aktuellsten Version ausprobiert. Mir meldet das HM-CC-RT-DN immer noch NACK im state.
Folgende Info sehe ich in der Übersicht zum _WindowRec


trigLast
virtualKitchenDoor:open
2014-01-06 13:41:22


In den peerIDs zum _WindowRec ist der virtuelle Fenster sensor drin.

Danke und Gruß, Achim

martinp876

Hallo Achim,

wie steht nun das Register burstRx im RT?
gepeert ist der Button auch im WindowsRec - korrekt?

Gruss Martin

anierbeck

Hi Martin,

ja den hatte ich bereits zum Manuellen umstellen aktiv geschaltet.
gepeert ist es mit dem WindowRec, ja.

hier nochmal meine aktuelle Config. Mit dem webCmd press ... mache ich noch  nichts, denn momentan sende ich das Signal noch von "hand" per set virtualKitchenDoor postEvent open

hier die entscheidende Konfiguration


# HM-CFG-USB
define HM_CFG_USB HMLAN localhost:1234
attr HM_CFG_USB hmId 8D0C2D
attr HM_CFG_USB hmLanQlen 1_min

define Flur.Thermostat CUL_HM 21BC87
attr Flur.Thermostat .devInfo 00FFFF
attr Flur.Thermostat .stc 59
attr Flur.Thermostat IODev HM_CFG_USB
attr Flur.Thermostat actCycle 000:10
attr Flur.Thermostat actStatus alive
attr Flur.Thermostat autoReadReg 4_reqStatus
attr Flur.Thermostat building Haus
attr Flur.Thermostat expert 2_full
attr Flur.Thermostat firmware 1.0
attr Flur.Thermostat group Flur
attr Flur.Thermostat icon hc_wht_regler
attr Flur.Thermostat model HM-CC-RT-DN
attr Flur.Thermostat peerIDs
attr Flur.Thermostat room Hall_Living
attr Flur.Thermostat serialNr KEQ0576971
attr Flur.Thermostat subType thermostat

define Flur.Thermostat_WindowRec CUL_HM 21BC8703
attr Flur.Thermostat_WindowRec expert 1
attr Flur.Thermostat_WindowRec model HM-CC-RT-DN
attr Flur.Thermostat_WindowRec peerIDs 00000000,22113301,
attr Flur.Thermostat_WindowRec room Hall_Living
attr Flur.Thermostat_WindowRec stateFormat last:trigLast

[... noch ein paar andere configs ...]

define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor peerIDs 21BC8703,
attr virtualKitchenDoor room 1_HEIZUNG
attr virtualKitchenDoor webCmd press short:press long

martinp876

Hi Achim,

die Frage war, was IM RT steht.
Schicke ein
list Flur.Thermostat_WindowRec
und
list Flur.Thermostat

und zeichne die rohmessages auf vom Ablauf

Gruss Martin

anierbeck

Hi Martin,

danke für den Hinweis.

vom Thermostat_WindowRec:

Internals:
   DEF        21BC8703
   NAME       Flur.Thermostat_WindowRec
   NR         53
   STATE      last:virtualKitchenDoor:open
   TYPE       CUL_HM
   chanNo     03
   device     Flur.Thermostat
   peerList   virtualKitchenDoor,
   CHANGETIME:
   Helper:
     Dblog:
       Triglast:
         Mydblog:
           TIME       1389126172.13053
           VALUE      virtualKitchenDoor:open
       Trig_virtualkitchendoor:
         Mydblog:
           TIME       1389126172.13053
           VALUE      open
   Readings:
     2014-01-03 17:25:53   CommandAccepted yes
     2014-01-05 00:33:11   R-sign          on
     2014-01-05 22:36:43   R-virtualKitchenDoor-shCtValLo 50
     2014-01-05 22:36:43   R-virtualKitchenDoor-winOpnTemp 12 C
     2014-01-06 13:36:46   peerList        virtualKitchenDoor,
     2014-01-07 21:22:52   trigLast        virtualKitchenDoor:open
     2014-01-05 00:58:22   trig_virSC1     open
     2014-01-07 21:22:52   trig_virtualKitchenDoor open
     2014-01-05 23:22:03   winOpnBoost     off
     2014-01-05 23:22:03   winOpnDetFall   1.4 K
     2014-01-05 23:22:03   winOpnMode      on
     2014-01-05 23:22:03   winOpnPeriod    15 min
     2014-01-05 23:22:03   winOpnTemp-int  12 C
   Helper:
     Role:
       chn        1
Attributes:
   expert     1
   model      HM-CC-RT-DN
   peerIDs    00000000,22113301,
   room       Hall_Living
   stateFormat last:trigLast


und nun vom Thermostat


Internals:
   CHANGED   
   DEF        21BC87
   HM_CFG_USB_MSGCNT 812
   HM_CFG_USB_RAWMSG E21BC87,0000,03BA80E2,FF,FFC9,34A00221BC8722113304109F0D09AC1100
   HM_CFG_USB_RSSI -55
   HM_CFG_USB_TIME 2014-01-07 21:22:53
   IODev      HM_CFG_USB
   LASTInputDev HM_CFG_USB
   MSGCNT     812
   NAME       Flur.Thermostat
   NR         41
   STATE      NACK
   TYPE       CUL_HM
   channel_01 Flur.Thermostat_Weather
   channel_02 Flur.Thermostat_Climate
   channel_03 Flur.Thermostat_WindowRec
   channel_04 Flur.Thermostat_Clima
   channel_05 Flur.Thermostat_ClimaTeam
   channel_06 Flur.Thermostat_remote
   lastMsg    No:34 - t:02 s:21BC87 d:221133 04109F0D09AC1100
   protCmdDel 0
   protEvt_AESok 20 last_at:2014-01-07 19:50:49
   protLastRcv 2014-01-07 21:22:53
   protNack   3 last_at:2014-01-07 21:22:53
   protResnd  2 last_at:2014-01-06 20:32:12
   protSnd    70 last_at:2014-01-07 21:22:52
   protState  CMDs_done_Errors:1
   rssi_at_HM_CFG_USB avg:-52.61 min:-69 max:-46 lst:-55 cnt:812
   CHANGETIME:
   Helper:
     Dblog:
       Activity:
         Mydblog:
           TIME       1389011806.30856
           VALUE      alive
       Actuator:
         Mydblog:
           TIME       1389126146.25149
           VALUE      60
       Battery:
         Mydblog:
           TIME       1389126146.25149
           VALUE      ok
       Batterylevel:
         Mydblog:
           TIME       1389126146.25149
           VALUE      3 V
       Desired-temp:
         Mydblog:
           TIME       1389126146.25149
           VALUE      21
       Measured-temp:
         Mydblog:
           TIME       1389126146.25149
           VALUE      22.1
       State:
         Mydblog:
           TIME       1389126173.57368
           VALUE      NACK
       Time-request:
         Mydblog:
           TIME       1389060156.85015
           VALUE      -
   Readings:
     2014-01-06 13:36:46   Activity        alive
     2014-01-07 21:22:53   CommandAccepted no
     2014-01-03 18:09:25   PairedTo        0x8D0C2D
     2013-12-22 00:11:06   R-backOnTime    10 s
     2014-01-03 18:04:11   R-btnLock       unlock
     2014-01-03 18:09:25   R-burstRx       on
     2014-01-03 18:04:11   R-cyclicInfoMsg on
     2014-01-03 18:04:11   R-cyclicInfoMsgDis 0
     2014-01-03 18:04:11   R-globalBtnLock off
     2014-01-03 18:04:11   R-localResDis   off
     2013-12-22 00:11:06   R-lowBatLimitRT 2.1 V
     2014-01-03 18:04:11   R-modusBtnLock  off
     2014-01-03 18:04:11   R-pairCentral   0x8D0C2D
     2014-01-03 18:09:25   RegL_00:        01:01 02:01 09:01 0A:8D 0B:0C 0C:2D 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-01-07 21:22:26   actuator        60 %
     2014-01-07 19:50:49   aesKeyNbr       FF
     2014-01-07 21:22:26   battery         ok
     2014-01-07 21:22:26   batteryLevel    3 V
     2014-01-07 21:22:26   desired-temp    21
     2014-01-07 21:22:26   measured-temp   22.1
     2014-01-07 21:22:53   state           NACK
     2014-01-07 03:02:36   time-request    -
   Helper:
     cSnd       118D0C2D21BC87810418
     mId        0095
     rxType     140
     Io:
       nextSend   1389126173.6946
     Prt:
       awake      0
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rpt:
       IO         HM_CFG_USB
       flg        A
       ts         1389126173.67695
       ack:
         HASH(0x28904b8)
         34800222113321BC8700
     Rssi:
       At_hm_cfg_usb:
         avg        -52.6169950738916
         cnt        812
         lst        -55
         max        -46
         min        -69
Attributes:
   IODev      HM_CFG_USB
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   building   Haus
   expert     2_full
   firmware   1.0
   group      Flur
   icon       hc_wht_regler
   model      HM-CC-RT-DN
   peerIDs   
   room       Hall_Living
   serialNr   KEQ0576971
   subType    thermostat
   webCmd     getConfig:burstXmit


noch eine frage wie kann ich denn die rohmessages aufzeichnen?
Dazu hab ich leider keine Doku gefunden.

Danke und Gruß, Achim

martinp876