HM virtual CCU

[frank]

hier ein getconfig von 1BFC52.

von deinem VD sehe ich noch nicht einmal eine config-message.

ich auch nicht! 
wenn ich die configtaste solange gedrückt halte, dass der 20 sekunden countdown startet, sollten doch cul, hmusb oder hmlan in der lage sein, etwas zu empfangen. oder?

gruss frank

[frank]

meine theorie ist folgende:
da ich vor dem getconfig ein set clear readings, reg, rssi und msgevents gemacht habe, das getconfig schief gegangen ist, ist das device nun unbekannt. und unbekannte devices werden ab heute nicht mehr empfangen.

update:
nach dem rückspielen der 00_cul_hm, konnte ich den einen vd nur über reset und batterie entfernernen neu anlernen. ein anderer konnte durch einfaches neu anlernen reannimiert werden.

gruss frank

[martinp876]

meine theorie ist folgende:
da ich vor dem getconfig ein set clear readings, reg, rssi und msgevents gemacht habe, das getconfig schief gegangen ist, ist das device nun unbekannt. und unbekannte devices werden ab heute nicht mehr empfangen.

ich kenne keinen weg, ein IO device (CUL oder HM...) zu sagen, dass bestimmte Addressen nicht empfangen werden dürfen/sollen. Das stimmt so also nicht.

nach dem rückspielen der 00_cul_hm,

das Modul kenne ich nicht. 10_CUL_HM?
Welche Version? Was ist Rückspielen?

konnte ich den einen vd nur über reset und batterie entfernernen neu anlernen. ein anderer konnte durch einfaches neu anlernen reannimiert werden.

hast du dies auch vor dem Rückspielen probiert?

Gruss Martin

[frank]

Welche Version? Was ist Rückspielen?

von

probiere CUL_HM 5763

zurück nach v5718

*****************************************************************

meine theorie ist folgende:
da ich vor dem getconfig ein set clear readings, reg, rssi und msgevents gemacht habe, das getconfig schief gegangen ist, ist das device nun unbekannt. und unbekannte devices werden ab heute nicht mehr empfangen.

ich kenne keinen weg, ein IO device (CUL oder HM...) zu sagen, dass bestimmte Addressen nicht empfangen werden dürfen/sollen. Das stimmt so also nicht.

mit v5718 erhalte ich folgende messages von einem vd, wenn ich mit der anlerntaste den countdown auslöse:

Code Auswählen Erweitern

2014.05.07 10:39:36.499 0: HMLAN_Parse: hmlan1 R:E1BFC52   stat:0000 t:02227C81 d:FF r:FFCD     m:B8 8400 1BFC52 000000 20003A4A45513034353830313858010100
2014.05.07 10:39:36.650 0: HMLAN_Parse: hmusb1 R:E1BFC52   stat:0000 t:01646902 d:FF r:FFCC     m:B8 8400 1BFC52 000000 20003A4A45513034353830313858010100

das hatte ich mit dem vd, den ich später nur über einen reset reannimieren konnte, auch mit version 5763 probiert. wie du selbst in meinem log aus beitrag 57 gesehen hast, sind messages vom typ 8400 von diesem vd nicht zu finden. von dem device war ja gar nichts zu finden.
und nein, ich hatte den reset mit v5763 nicht probiert.

*****************************************************************

hast du das log aus beitrag #60 angeschaut?
so wie ich das sehe, geht da etwas mit den msg-nummern schief.
nach der valvepos übergabe mit m17 sendet hmlan die configanfrage mit m35 (hmlan_send). die hmlan_parse einträge enthalten aber weiterhin m17.

[martinp876]

irgendwie kann ich das mit message-Unterdrücken nicht glauben. CUL_HM kommt erst nach den rohmessages.
Möglich ist schon (eigentlich sicher), dass man an den HMLAN weitere Konfig-kommandos senden kann. Aber eine zum blockieren kenne ich noch nicht.

Ich halte es für Zufall.
Die Config message mit der neusten Version kommt mit meinem VD an.

Gruss Martin

[frank]

hier noch ein schönes beispiel von vd 1C4E25. das log zum bild findest du in beitrag #57. auch hier meine ich, gibt es ungereimtheiten mit den msg-nummern.

gegen 15:00 läuft der vd noch.
dann um 15:20 sende ich ein set getconfig. gefolgt von miss3 und miss4.
um15:33 ein lebenszeichen und fhem wiederholt den config versuch. vd schläft ein.

nach einer stunde wacht er noch einmal auf. (das ist in log von beitrag #57 nicht mehr enthalten. könntest du aber bekommen.) daraufhin kann fhem über stunden keinen kontakt mehr herstellen. eigentlich müsste fhem jede stunde mindestens einmal kontakt haben.

gruss frank

[martinp876]

Hallo Frank,

hm- es gibt einige Probleme. Der VD meldet nicht "aufgewacht" wenn er vom vtc angesprochen wird - was er tut, wenn ein TC sendet.

Zum 1. solltest du beim VD einstellen
attr <vd> msgRepeat 0
- sonst werden fehlgeschlagene messages wiederholt.

zum 2. - wenn nach einer valvePos-message ein mögliches getConfig übertragen werden soll muss erst einmal eine andere message gesendet werden.

Dann kommen wir mit den message-nummern in Schwierigkeiten.

Ich bastle einmal...

Gruss Martin

[martinp876]

Hi,
Anbei eine test-version zur automatischen IO-selektion über vccu.
Vorgehen:
Definiere eine CCU und weise IOs zu

Code Auswählen Erweitern

define ccu CUL_HM 1743BF
attr ccu IODev IOdev1
attr ccu IOList IOdev1,IOdev2,IOdev3,...
attr ccu model CCU-FHEM
attr ccu subType virtual
1743BF ist die ID der CCU. Diese wird in die IO devices eingetragen - als HMId. (CCU geht noch nicht automatisch...)
attr ccu IODev IOdev1 : die CCU wird primär über dieses IO senden
attr ccu IOList IOdev1,IOdev2,IOdev3,... : hier werden alle für diese CCU erlaubten IOs zugewiesen

Device einer CCU zuordnen

Code Auswählen Erweitern

attr <dev>   IODev      IOdev1
attr <dev>   IOgrp      ccu
IODev ist nun nachrangig - wird nicht mehr genutzt. Da es aber auch vom kernal genutzt wird muss es erhalten bleiben.
IOgrp: hier wird die ccu eingetragen

Code Auswählen Erweitern

attr <dev>   IOgrp      ccu:IOdev1
Alternativ kann man ein prefered io angeben.

Ablauf
Beim Senden wird ein IO dynamisch zugewiesen nach folgenden Regeln
- das IO muss operationell sein (nicht disconnect, kein Overload,...)
- das prefered IO ist erste Wahl
- entsprechend der RSSI level wird das beste IO gewaehlt

Falls jemand testet - Erfahrungen, Anregungen, Problem bitte mitteilen

Gruss Martin

[hexenmeister]

Hallo Martin,

habe gerade die Testversion eingespielt und meine 2 IO-Devices (HMLAN und HMUSB-CFG) zugeordnen. Dann einige ausgewählte HM-Geräte (UP Schalter, Dimmer und 2 Rolladenaktoren) mit IOGrp versorgt. Aus den ersten Blick funktioniert alles gut. Morgen will ich versuchen, die Sender gezielt einzeln lahmzulegen. Bin gespannt 

Ansponsten schon mal riesen Dank, diese Feature hat mir schon lange gefehlt, es ist ein großer Schritt in die Richtung Ausfallsicherheit! 

Grüße,

Alexander

[hexenmeister]

So, habe ein wenig getestet...
Es funktioniert grundsätzlich, hat aber ein Problem mit HMUSB.

Wenn ich HMLAN abziehe, wird das sofort und zuverlässig erkannt. Bei HMUSB ist das anders. Ich vermute, das liegt daran, dass HMUSB nicht direkt, sondern über einen Demon angesteuert wird.
Beim 'abklemmen' sieht Status der Devices unterschiedlich aus. Bei HMLAN steht 'disconnected', bei HMUSB dagegen 'init'
und log füllt sich mit folgenden Meldungen:

Code Auswählen Erweitern

2014.05.20 20:50:45.789 1: HMLAN_Parse: hmusb new condition disconnected
2014.05.20 20:50:45.818 1: 127.0.0.1:1234 reappeared (hmusb)
2014.05.20 20:50:45.838 1: HMLAN_Parse: hmusb new condition init
2014.05.20 20:50:46.796 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)

Im CCU steht dann für HMUSB 'ok' und das Senden an die HM-Komponenten läuft schief.
Wenn das Problem behoben ist, wird die virtuelle CCU für mich unverzichtbar


Grüße,

Alexander

[martinp876]

Hallo Alexander,

der Code ist eingecheckt. Mit  noch ein paar verbesserungen.

Das HMUSB solchen status sendet ist schade... ist schon unangenehm, das CUL und HMLAN abweichen.
bei HMLAN ist
- disconnected # klar
- init # gerade initialisiert - bereit zum senden
- opened # im operationellen betrieb
Ausserdem habe ich noch die Overload indikatoren

Bei CUL habe ich
- Initialized # normalbetrieb
- disconnected # klar

Welche Zustände erreicht jetzt HMUSB? Kannst du dies noch einmal zusammenfassen?

Gruss Martin

[hexenmeister]

Hallo Martin,

gestern kam ich leider nicht mehr dazu, daher erst jetzt.

Ich habe folgenden Stati beobachten können:

• disconnected: wenn Daemon komplett gestoppt ist
• init: wenn Daemon läuft, aber der Stick (noch) nicht ansprechbar ist => hier ist nichts sendebereit
• ok: Daemon läuft, Stick angeschlossen => es kann gesendet werden.

Auszüge aus dem Log:

Daemon gestoppt:

Code Auswählen Erweitern

2014-05-22_17:07:38 hmusb DISCONNECTED


Daemon wieder starten (dauert etwas, bis der neue Status 'ankommt'):

Code Auswählen Erweitern

2014-05-22_17:08:39 hmusb cond: init
2014-05-22_17:08:39 hmusb Xmit-Events: init:1
2014-05-22_17:08:39 hmusb prot_init: last
2014-05-22_17:08:39 hmusb CONNECTED
2014-05-22_17:08:39 hmusb cond: ok
2014-05-22_17:08:39 hmusb Xmit-Events: ok:1
2014-05-22_17:08:39 hmusb prot_ok: last

Stick abziehen (Deamon läuft natürlich):

Code Auswählen Erweitern

2014-05-22_17:10:03 hmusb DISCONNECTED
2014-05-22_17:10:03 hmusb cond: init
2014-05-22_17:10:03 hmusb Xmit-Events: init:1
2014-05-22_17:10:03 hmusb prot_init: last
2014-05-22_17:10:03 hmusb CONNECTED
2014-05-22_17:10:05 hmusb DISCONNECTED
2014-05-22_17:10:05 hmusb cond: init
2014-05-22_17:10:05 hmusb Xmit-Events: init:1
2014-05-22_17:10:05 hmusb prot_init: last
2014-05-22_17:10:05 hmusb CONNECTED
2014-05-22_17:10:05 hmusb DISCONNECTED
2014-05-22_17:10:05 hmusb cond: init
2014-05-22_17:10:05 hmusb Xmit-Events: init:1
2014-05-22_17:10:05 hmusb prot_init: last
2014-05-22_17:10:05 hmusb CONNECTED
2014-05-22_17:10:06 hmusb DISCONNECTED
2014-05-22_17:10:06 hmusb cond: init
2014-05-22_17:10:06 hmusb Xmit-Events: init:1
2014-05-22_17:10:06 hmusb prot_init: last
2014-05-22_17:10:06 hmusb CONNECTED
2014-05-22_17:10:07 hmusb DISCONNECTED
2014-05-22_17:10:07 hmusb cond: init
2014-05-22_17:10:07 hmusb Xmit-Events: init:1
2014-05-22_17:10:07 hmusb prot_init: last
2014-05-22_17:10:08 hmusb CONNECTED
2014-05-22_17:10:08 hmusb DISCONNECTED
2014-05-22_17:10:08 hmusb cond: init
2014-05-22_17:10:08 hmusb Xmit-Events: init:1
2014-05-22_17:10:08 hmusb prot_init: last
2014-05-22_17:10:09 hmusb CONNECTED
2014-05-22_17:10:09 hmusb DISCONNECTED
2014-05-22_17:10:10 hmusb cond: init
2014-05-22_17:10:10 hmusb Xmit-Events: init:1
2014-05-22_17:10:10 hmusb prot_init: last
2014-05-22_17:10:10 hmusb CONNECTED
2014-05-22_17:10:10 hmusb DISCONNECTED
2014-05-22_17:10:11 hmusb cond: init
2014-05-22_17:10:11 hmusb Xmit-Events: init:1
2014-05-22_17:10:11 hmusb prot_init: last
2014-05-22_17:10:11 hmusb CONNECTED
2014-05-22_17:10:12 hmusb DISCONNECTED
2014-05-22_17:10:12 hmusb cond: init
2014-05-22_17:10:12 hmusb Xmit-Events: init:1
2014-05-22_17:10:12 hmusb prot_init: last
2014-05-22_17:10:12 hmusb CONNECTED
2014-05-22_17:10:13 hmusb DISCONNECTED
2014-05-22_17:10:13 hmusb cond: init
2014-05-22_17:10:13 hmusb Xmit-Events: init:1
2014-05-22_17:10:13 hmusb prot_init: last
2014-05-22_17:10:13 hmusb CONNECTED
2014-05-22_17:10:14 hmusb DISCONNECTED
2014-05-22_17:10:15 hmusb cond: init
2014-05-22_17:10:15 hmusb Xmit-Events: init:1
2014-05-22_17:10:15 hmusb prot_init: last
2014-05-22_17:10:15 hmusb CONNECTED
2014-05-22_17:10:15 hmusb DISCONNECTED
2014-05-22_17:10:15 hmusb cond: init
2014-05-22_17:10:15 hmusb Xmit-Events: init:1
2014-05-22_17:10:15 hmusb prot_init: last
2014-05-22_17:10:15 hmusb CONNECTED
2014-05-22_17:10:16 hmusb DISCONNECTED
2014-05-22_17:10:16 hmusb cond: init
2014-05-22_17:10:16 hmusb Xmit-Events: init:1
2014-05-22_17:10:16 hmusb prot_init: last
2014-05-22_17:10:16 hmusb CONNECTED
2014-05-22_17:10:17 hmusb DISCONNECTED
2014-05-22_17:10:17 hmusb cond: init
2014-05-22_17:10:17 hmusb Xmit-Events: init:1
2014-05-22_17:10:17 hmusb prot_init: last
2014-05-22_17:10:17 hmusb CONNECTED
2014-05-22_17:10:18 hmusb DISCONNECTED
2014-05-22_17:10:18 hmusb cond: init
2014-05-22_17:10:18 hmusb Xmit-Events: init:1
2014-05-22_17:10:18 hmusb prot_init: last
2014-05-22_17:10:18 hmusb CONNECTED
2014-05-22_17:10:19 hmusb DISCONNECTED
2014-05-22_17:10:19 hmusb cond: init
2014-05-22_17:10:19 hmusb Xmit-Events: init:1
2014-05-22_17:10:19 hmusb prot_init: last
2014-05-22_17:10:19 hmusb CONNECTED
2014-05-22_17:10:20 hmusb DISCONNECTED
2014-05-22_17:10:20 hmusb cond: init
2014-05-22_17:10:20 hmusb Xmit-Events: init:1
2014-05-22_17:10:20 hmusb prot_init: last
2014-05-22_17:10:20 hmusb CONNECTED
2014-05-22_17:10:21 hmusb DISCONNECTED
2014-05-22_17:10:21 hmusb cond: init
2014-05-22_17:10:21 hmusb Xmit-Events: init:1
2014-05-22_17:10:21 hmusb prot_init: last
2014-05-22_17:10:21 hmusb CONNECTED
2014-05-22_17:10:22 hmusb DISCONNECTED
2014-05-22_17:10:22 hmusb cond: init
2014-05-22_17:10:22 hmusb Xmit-Events: init:1
2014-05-22_17:10:22 hmusb prot_init: last
2014-05-22_17:10:22 hmusb CONNECTED
2014-05-22_17:10:25 hmusb DISCONNECTED
2014-05-22_17:10:25 hmusb cond: init
2014-05-22_17:10:25 hmusb Xmit-Events: init:1
2014-05-22_17:10:25 hmusb prot_init: last
2014-05-22_17:10:25 hmusb CONNECTED
2014-05-22_17:10:26 hmusb DISCONNECTED
2014-05-22_17:10:26 hmusb cond: init
2014-05-22_17:10:26 hmusb Xmit-Events: init:1
2014-05-22_17:10:26 hmusb prot_init: last
2014-05-22_17:10:26 hmusb CONNECTED
2014-05-22_17:10:26 hmusb DISCONNECTED
2014-05-22_17:10:26 hmusb cond: init
2014-05-22_17:10:26 hmusb Xmit-Events: init:1
2014-05-22_17:10:26 hmusb prot_init: last
2014-05-22_17:10:26 hmusb CONNECTED
2014-05-22_17:10:27 hmusb DISCONNECTED
2014-05-22_17:10:27 hmusb cond: init
2014-05-22_17:10:27 hmusb Xmit-Events: init:1
2014-05-22_17:10:27 hmusb prot_init: last
2014-05-22_17:10:27 hmusb CONNECTED
2014-05-22_17:10:28 hmusb DISCONNECTED
2014-05-22_17:10:28 hmusb cond: init
2014-05-22_17:10:28 hmusb Xmit-Events: init:1
2014-05-22_17:10:28 hmusb prot_init: last
2014-05-22_17:10:28 hmusb CONNECTED

Stick wieder einstecken:

Code Auswählen Erweitern

2014-05-22_17:10:30 hmusb cond: ok
2014-05-22_17:10:30 hmusb Xmit-Events: ok:1
2014-05-22_17:10:30 hmusb prot_ok: last

Es sieht so aus, dass CCU nur dann HMUSB verwenden darf, wenn dieser in Status ok ist.
Baust Du das entsprechend ein? Danke im Voraus

Grüße,

Alexander

EDIT: Wenn ich Daemon stoppe, wird das schon jetzt zuverlässig erkannt, nur eben nicht, wenn der Stick 'nicht da' ist.

[martinp876]

Das Problem ist, dass ich den HMUSB nicht erkennen kann. Der sieht aus wie ein HMLAN.
Ich koennte init aus HMLAN entfernen - macht nicht wirklich viel sinn.

nein, ich denke, ich werden init bei HMLAN/USB nicht als aktiv werten. Muss ich aber noch pruefen.

Gruss Martin

[hexenmeister]

Das Problem ist, dass ich den HMUSB nicht erkennen kann.

Das habe ich schon befürchtet.
Aber auch die Idee, es nicht als aktiv bzw. sendebereit zu werten müsste wohl gut funktionieren. Oder siehst Du dabei bestimmte Nachteile?


Grüße,

Alexander

[martinp876]

Probiere einmal das CUL_HM von heute aus SVN (morgen im Update). Ich hoffe, das löst das Problem.