HM virtual CCU

[betateilchen]

Ein device ist mit einen IO gepairt... das stimmt so nicht, insbesondere wenn es mehrere IOs gibt.

Ein device ist doch eigentlich auf die ID des IO gepairt. Und wenn es fünf IOs gibt, die alle die gleiche ID haben, ist das überhaupt kein Problem und die einfachste Weise, die Ausdehnung des Versorgungsgebietes zu erweitern, weil es dem device völlig wurscht ist, welches IO ihm antwortet, solange die ID stimmt.

[martinp876]

praktisch hast du recht - und daran wird sich auch nichts ändern.
Und wenn wir und nur über HMIds unterhalten ist auch (fast) alles prima.
Wenn jetzt aber dargestellt werden soll, mit wem ein channel gepeert ist, und wir KEINE ccu haben gibt es nur Probleme. Wir wollen einen Namen, keine Nummer.
- die HMId ist nicht im CUL_HM Schema
- man könnte das IODevice prüfen und den Namen des IO eintragen.
=>Gleiche HMId führt zu unterschiedlichen Namen
=>Änderung des Attribut IODev ändert den Namen des peers
- man kann den Namen des IO prüfen und "fhem" eintragen (so ist es gerade)
- sollte man mehrere HMId für IO nutzen (hast du nicht, magst du nicht, weiss ich... ist aber trotzdem zulässig) dann haben die den gleichen Namen (fhem)

Ein device ist doch eigentlich auf die ID des IO gepairt

das genau ist der Punkt. Wenn du betrachtest, was HM in seiner CCU macht, ist es genau, was ich beschreibe. Die CCU hat eine HMId. gepairt wird mit der CCU.
Man kann weitere IOs dazu bauen. Und dann kann man der CCU sagen, über welches IO an mit einem Speziell Device sprechen will.

In FHEM wurde die Flexibilität eingebaut, dass  (implizit) die Zentrale mehrere HMIds haben KANN (nicht muss). Praktisch wird dies bei CUL sogar automatisch vergeben (m.E. sehr unschön). Ich sehe keinen Grund, dies zu unterbinden. Diese Flexibilität kostet nichts - vielleicht kann es einmal einer gut nutzen.
Zu empfehlen ist in erster Linie dein Angang als default: nur eine HMId.

Prima wäre:
- CCU definieren (hat als CUL_HM auch eine HMId)
- IO devices der CCU assignen
=> CCU setzt die HMId in den IOs
=> in assigned IOs kann man die HMId nicht mehr ändern - erst wenn man sie von der CCU trennt.
Die CCU wird intern über wichtige "Probleme" des IO informiert (disconnect,...) und zeigt dies an
In einem weiteren Schritt könnte man dann Ersatzschalten... kann aber problematisch sein (reichweite...) Topographie der IOs

Das sollte dann deiner Philosophie sehr entgegen kommen. Du steuerst die IOs von der CCU - so soll es sein.

Gruss Martin

[betateilchen]

Bis auf den letzten Satz hab ich alles verstanden.

[martinp876]

Bis auf den letzten Satz hab ich alles verstanden.

hm - verstanden - soll heißen?

Der letzte Satz soll aussagen, dass ein Konzept "ganzes System mit einer HMId für alle IOs" - was dein Konzept ist - gut zu steuern und überwachen sein sollte.

Hi Frank

.. hatte ich aber iodev bei der vccu bereits auf hmlan geändert. ...

die HMId der CCU ist die im Define.
Das Ändern des Attributs IODev ändert daran nichts. Es sollte(muss ) eingebaut werden, dass das IODev der CCU auch nur einem IO mit der HMId des "DEF" zugewiesen werden kann.
Realisierung besser anders herum - CCU attribute
- attr IODevList <liste der IOs der CCU>
- attr IODev <prefered IO der CCU selbst - eines aus der Liste in IODevList>
Kann dies dein Problem gewesen sein?

[frank]

Kann dies dein Problem gewesen sein?

ich glaube nicht. also noch mal langsam.

damals als es noch keine vccu gab hatte ich 2 iodevices. hmlan mit hmid 123ABC und cul mit hmid C1C1C1.

dann habe ich eine vccu definiert mit "define ccu cul_hm 123ABC".

nun hatte die ccu assignedIOs=hmlan (hört sich passend an).

aber! bei attr iodev hatte die ccu cul eingetragen. (das finde ich komisch).

dann habe ich bei attr iodev der ccu => hmlan eingetragen. per hand. keine listenauswahl. die ccu hatte ja auch nur ein io zugewiesen bekommen. und zwar durch ihre definition.

gruss frank

[ManfredC]

Hallo,

ich weiss nicht, ob Du Dich an unser gemeinsam gelöstes Problem vor ein paar Monaten erinnerst, als die ersten RC-4-2 auf den Markt kamen und es lange das Problem gab, dass ich nicht zuverlässig eine grüne Bestätigung für die Fernbedienungsbuttons gab. Auch nicht mit virtuellen Aktoren.

hier seit ungefähr dem Osterwochenende keine grüne Bestätigung mehr. Backup eingespielt, ging wieder. Habe mich heute dem Problem angenommen, ein Update gemacht: wieder kaputt. Ein PB-6-WM ist mit Rolladenaktoren und eben einem virtuellen Actor gepeert. Das Peering zum virtuellen Actor entfernt: grüne Bestätigung geht wieder.

Die Lösung war seinerzeit, die Fernbedienungsbuttons direkt mit dem HMUSB zu peeren, was völlig problemlos funktionierte und seither auch immer die korrekte Rückmeldung liefert.

Aufgrund dieses Threads habe ich den PB-6 nun direkt mit HMLAN gepeert: Bestätigung wieder da. Ich möchte schon das sowohl der Actor als auch FHEM die Befehle quittieren. Wenn es denn so geht, solls mir auch recht sein 

Gruß,

Manfred

[martinp876]

@frank,

das IODev in Internals wird primär in der Zentrale (fhem.pl) ausgewürfelt. Bei der Behandlung der IOs (IO-Liste der CCU fixieren, setzen von Parametern in den IOs) sollte sich dann noch einiges tun...

@Manfred
wir haben ein Problem mit SC durchgespielt - je nach FW und Peering (nicht virtuell, sondern Real ) ändert sich die  LED-farbe...
Welche Version war die, die Grün liefert?
Kannst du einmal rohmessages aufzeichnen, wenn es rot wird?

[martinp876]

habe einmal den nächsten Schritt eingebaut.
mit
attr ccu IOList io1,io2,io3
kann man die IOs eintragen, die von der CCU aus bedient werden sollen. Im STATE wird nach update deren Zustand angezeigt. UAS eines IO bedeutet, dass es die gleiche HMId wie die CCU hat, aber nicht in der Liste steht, also UnASsigned ist.
IOs aus der Liste werden konfiguriert. Die HMId wird gesetzt (und kann bei HMLAN nicht mehr geändert werden), bei der CUL wird der rfmode gesetzt - mehr nicht.
die HMId des HMLAN kann man erst wieder ändern, wenn es nicht mehr der CCU assigned ist (aus der Liste löschen).
Aktuell wird nicht alles sofort aktualisiert, ein "update" der CCU ist notwendig.

Gruss Martin

[frank]

ich beobachte gerade ein seltsames verhalten vom reading msgloadest meines hmlan. obwohl er wenig senden muss, steigt der wert kontinuierlich.

ich habe cul und hmlan, beide mit selber hmid. sind beide mit vccu assigned.

der cul hat reichlich zu tun. er muss einem schalter alle 2 sekunden antworten. nun scheint es so, dass der traffic des cul zur berechnung des msgloadest des hmlan benutzt wird. kann das an der vccu liegen? oder kommt das durch die selben hmid? anbei ein kurzer log auszug. die nacht über hatte sich der wert bei ca 150% eingependelt. der reale hmlan anteil müsste um 10% gelegen haben. der hmlan hat natürlich keinen overload gemeldet.

Code Auswählen Erweitern

2014.05.01 20:46:05.153 4: CUL_send:  cul868As 0A F0 8002 123ABC 266EA5 00
2014.05.01 20:46:05.168 4: SND L:0A N:F0 F:80 CMD:02 SRC:ccu DST:SwitchPBU01 00 (ACK) (,RPTEN)
2014.05.01 20:46:05.231 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:04721D2A d:FF r:FFD0     m:F0 A410 266EA5 123ABC 0604000000
2014.05.01 20:46:05.244 0: HMLAN_Parse: HMLAN1 R:E123ABC   stat:0000 t:04721DB0 d:FF r:FFE1     m:F0 8002 123ABC 266EA5 00
2014.05.01 20:46:07.155 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:04722485 d:FF r:FFD0     m:F1 A410 266EA5 123ABC 0604000000
2014.05.01 20:46:07.232 4: CUL_send:  cul868As 0A F1 8002 123ABC 266EA5 00
2014.05.01 20:46:07.247 4: SND L:0A N:F1 F:80 CMD:02 SRC:ccu DST:SwitchPBU01 00 (ACK) (,RPTEN)
2014.05.01 20:46:07.308 4: CUL_Parse: cul868 A 0E F1 A410 266EA5 123ABC 06040000000A -69
2014.05.01 20:46:07.441 0: HMLAN_Parse: HMLAN1 R:E123ABC   stat:0000 t:047225CF d:FF r:FFE1     m:F1 8002 123ABC 266EA5 00
2014.05.01 20:46:08.625 4: CUL_Parse: cul868 A 0E F2 A410 266EA5 123ABC 060400000009 -69.5
2014.05.01 20:46:08.636 4: RCV L:0E N:F2 F:A4 CMD:10 SRC:SwitchPBU01 DST:ccu 0604000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x04 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2014.05.01 20:46:08.741 4: CUL_send:  cul868As 0A F2 8002 123ABC 266EA5 00
2014.05.01 20:46:08.758 4: SND L:0A N:F2 F:80 CMD:02 SRC:ccu DST:SwitchPBU01 00 (ACK) (,RPTEN)
2014.05.01 20:46:08.863 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:04722B1A d:FF r:FFCF     m:F2 A410 266EA5 123ABC 0604000000
2014.05.01 20:46:08.875 0: HMLAN_Parse: HMLAN1 R:E123ABC   stat:0000 t:04722BB4 d:FF r:FFE1     m:F2 8002 123ABC 266EA5 00
2014.05.01 20:46:10.297 4: CUL_Parse: cul868 A 0E F3 A410 266EA5 123ABC 060400000009 -69.5
2014.05.01 20:46:10.349 4: RCV L:0E N:F3 F:A4 CMD:10 SRC:SwitchPBU01 DST:ccu 0604000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x04 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2014.05.01 20:46:10.409 4: CUL_send:  cul868As 0A F3 8002 123ABC 266EA5 00
2014.05.01 20:46:10.431 4: SND L:0A N:F3 F:80 CMD:02 SRC:ccu DST:SwitchPBU01 00 (ACK) (,RPTEN)
2014.05.01 20:46:10.507 0: HMLAN_Parse: HMLAN1 R:E266EA5   stat:0000 t:047231A8 d:FF r:FFD0     m:F3 A410 266EA5 123ABC 0604000000
2014.05.01 20:46:10.521 0: HMLAN_Parse: HMLAN1 R:E123ABC   stat:0000 t:04723239 d:FF r:FFE1     m:F3 8002 123ABC 266EA5 00
2014.05.01 20:46:11.453 4: CUL_Parse: cul868 A 0E F4 A410 266EA5 123ABC 06040000000C -68
2014.05.01 20:46:11.464 4: RCV L:0E N:F4 F:A4 CMD:10 SRC:SwitchPBU01 DST:ccu 0604000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x04 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)

hier noch mal ein list vom hmlan:

Code Auswählen Erweitern

Internals:
   DEF        192.168.1.9:1000
   DeviceName 192.168.1.9:1000
   FD         30
   HMLAN1_MSGCNT 4882
   HMLAN1_TIME 2014-05-01 21:12:54
   HM_CMDNR   26
   NAME       HMLAN1
   NR         30
   NTFY_ORDER 50-HMLAN1
   PARTIAL
   RAWMSG     E123ABC,0000,048AAB44,FF,FFE1,7C8002123ABC266EA500
   RSSI       -31
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDs 24AF1D,266A86,1C4E25,1BF81B,1936FF,1F64D8,1DFC2F,1DF7C6,1BFC52,193A9A,1CE9F5,1D252E,1DFDA5
   assignedIDsCnt 13
   assignedIDsReport 13
   firmware   0.961
   msgKeepAlive dlyMax:3.672 bufferMin:1
   msgLoadEst 1hour:103% 10min steps: 5/21/18/18/20/19
   msgParseDly min:1 max:3618 last:73 cnt:4667
   owner      123ABC
   owner_CCU  ccu
   serialNr   JEQ0315335
   uptime     000 21:09:56.676
   .clientArray:
     CUL_HM
   Readings:
     2014-05-01 20:02:13   Xmit-Events     ok:1
     2014-05-01 20:02:13   cond            ok
     2014-05-01 21:12:38   hmAlive         dlyMax:3.672 bufferMin:1
     2014-05-01 21:12:38   hmDelay         min:1 max:3618 last:49 cnt:4647
     2014-05-01 21:12:38   hmTrfHour       103 %
     2014-05-01 21:12:38   hmTrfStr        1hour:103% 10min steps: 5/21/18/18/20/19
     2014-04-30 23:12:38   prot_ERROR-Overload last
     2014-04-30 23:29:21   prot_Warning-HighLoad last
     2014-05-01 20:02:12   prot_disconnected last
     2014-05-01 20:02:12   prot_init       last
     2014-02-11 20:34:53   prot_keepAlive  last
     2014-05-01 20:02:13   prot_ok         last
     2014-05-01 20:02:11   prot_timeout    last
   Assids:
     1936FF     1
     193A9A     1
     1BF81B     1
     1BFC52     1
     1C4E25     1
     1CE9F5     1
     1D252E     1
     1DF7C6     1
     1DFC2F     1
     1DFDA5     1
     1F64D8     1
     24AF1D     1
     266A86     1
   Helper:
     000001:
       flg        0
       msg
       to         1398967334.92999
     123abc:
       flg        0
     1936ff:
       chn        01
       flg        0
       msg
       name       Thermostat.Bad
       to         1398967412.59196
     193a9a:
       chn        00
       flg        0
       name       Ventil.Bad
     1bf81b:
       chn        01
       flg        0
       msg
       name       Thermostat.WZ
       to         1398967542.69342
     1bfc52:
       chn        00
       flg        0
       name       Ventil.Kueche
     1c4e25:
       chn        00
       flg        0
       name       Ventil.AZ.Nord
     1ce9f5:
       chn        00
       flg        0
       name       Ventil.WZ
     1d252e:
       chn        01
       flg        0
       msg
       name       Thermostat.Kueche
       to         1398967437.51327
     1df7c6:
       chn        01
       flg        0
       msg
       name       Tuer.WZ.Terrasse
       to         1398968754.12715
     1dfc2f:
       chn        00
       flg        0
       name       Ventil.SZ
     1dfda5:
       chn        01
       flg        0
       msg
       name       Thermostat.SZ
       to         1398967493.61038
     1f64d8:
       chn        01
       flg        0
       msg
       name       DimUP01
       to         1398967337.7473
     24af1d:
       chn        03
       flg        0
       msg
       name       SwitchES01
       to         1398967354.88565
     266a86:
       chn        03
       flg        0
       msg
       name       DimPBU01
       to         1398967336.93254
     266e75:
       chn        01
       flg        1
       msg
       name       CUL_HM_HM_LC_Sw1PBU_FM_266E75
       to         1398967332.60385
     Bm:
       Hmlan_notify:
         cnt        8431
         dmx        0
         mAr        HASH(0xc3a340); HASH(0xde8d48)
         max        16
         tot        49
       Hmlan_read:
         cnt        3308
         dmx        0
         mAr        HASH(0xc3a340)
         max        598
         tot        272937
       Hmlan_ready:
         cnt        1
         dmx        0
         mAr        HASH(0xc3a340)
         max        159
         tot        159
       Hmlan_set:
         cnt        1654
         dmx        0
         mAr        HASH(0xc3a340); HMLAN1; ?
         max        2
         tot        6
     Dly:
       cnt        4667
       lst        73
       max        3618
       min        1
     K:
       BufMin     1
       DlyMax     3.672
       Next       1398971589.74137
       Start      1398971564.74137
     Log:
       all        0
       sys        0
       ids:
         266EA5
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          9850
         1          2611
         2          8620
         3          9010
         4          8183
         5          8482
         last       1
         sum        46756
     Ref:
       drft       -0.000159942420728538
       hmtL       76187382
       kTs        0
       offL       1398895377367
       sysL       1398971564749
Attributes:
   event-on-change-reading .*
   hmId       123ABC
   hmLanQlen  1_min
   hmProtocolEvents 3_dumpTrigger
   logIDs     SwitchPBU01
   room       90_Technik
   wdTimer    25

gruss frank

[martinp876]

nun scheint es so, dass der traffic des cul zur berechnung des msgloadest des hmlan benutzt wird.

sollte nicht sein. HMLAN sendet ja nichts. Es wird aber empfangen - empfangen erzeugt keinen Overload.
Die Load des HMLAN wird im HMLAN errechnet, anhand der Sendemessages. Also darf es nicht zählen, wenn die CUL das Senden übernimmt.
Muss ich einmal testen.

[martinp876]

sollte mit 00_HMLAN V5725 berücksichtigt werden

[frank]

hallo martin,

die berechnung ansich funktioniert jetzt, aber noch nicht praktikabel. wenn ich meinen "gesprächigen" schalter umassigne von io1 auf io2, wird die kommunikation mit dem schalter zur berechnung beider io benutzt. erst nach shutdown restart ist alles in ordnung.

das verhalten könnte mit folgender beobachtung zusammenhängen:

ich benutze die vccu nun mit 3 io-devices: cul, hmlan, hmusb. in der ccu habe ich das neue attr iolist für die 3 io gesetzt.

wenn ich nun hm-devices von hmlan auf hmusb umassigne, werden die geänderten devices nur beim hmusb unter assignedIDs hinzugefügt, aber nicht beim hmlan entfernt. sie tauchen nun in beiden io auf. erst nach restart sind die listen ok. ausserdem erscheinen grundsätzlich die virtuellen devices gar nicht. wäre schön, wenn dem so wär.

schade, dass beim cul keine assignedIDs zu sehen sind. msgloadest würde dem cul auch gut stehen. aber wie du bereits zu logIDs gesagt hast, ist das nicht deine baustelle.
ersatzweise wäre die ausgabe einer tabelle mit zb "get assignedIDReport" sehr komfortabel, aus der sehr übersichtlich zu entnehmen ist, welches io mit welchem device assigned ist. dabei vielleicht folgende spalten: device_name, device_id, io01, io02, io3, .... . die io gemäss der liste bei attr ioList. je nach einstellung der devices dann ein kreuzchen. 
der absolute knüller wäre natürlich statt der kreuzchen zb radio-buttons, um die einstellungen der ioDev der hm-devices gleich zentral und komfortabel ändern (managen) zu können. 

weiterhin sind mir einige unterschiede bei hmlan und hmusb aufgefallen.
keepAlive mechanismus: hier gibt es ja auch das frage und antwort spiel. aber ein entsprechendes reading prot_keepAlive hat es noch nicht gegeben, obwohl ich das bei meinen tests bereits erwartet hätte. braucht es zum auslösen des readings weitere infos vom hmusb, die dieser nicht unterstützt, oder bedeutet das, dass der hmusb nicht so anfällig wie der hmlan ist?
highload, overload: wird wohl vom hmusb nicht unterstützt?
msgparsedelay: geben die raw-messages wohl nicht her?

zum heutigen schluss noch dies:
mit 2 oder mehr io könnte man doch auch über eine direkte sendeüberwachung der io nachdenken. dann wüsste man bei cul und hmusb auch, wenn das senden eingestellt ist. 

edit:
ich habe den hmusb jetzt mit nur 4 virtuellen vd assignes. als ergebnis nach restart stehen nun unter internals assignedids 4 tc. diese sind mit den vvd gepeert, sind selber aber mit dem hmlan assigned, wodurch sie nun sowohl bei hmlan als auch bei hmusb eingetragen sind.
eigenwillig ist auch das state reading. zeigt eigentlich immer info cleared an. durch set ccu update bekomme ich zwar unter internals STATE einen status der 3 io angezeigt, wohl aber nur, weil die internals werte sich nicht selber aktualisieren. was bedeuted info cleared?

gruss frank

[martinp876]

wird die kommunikation mit dem schalter zur berechnung beider io benutzt.

das ist wohl korrekt

erst nach shutdown restart ist alles in ordnung.

das ist eher ein Bug.

Du sprichst von den ACKs? Die sendet ein HMLAN ab dem Zeitpunkt, wenn das Device zu ihm assigned wird.
Aktuell kannst du nur unassignen, wenn du das HMLAN rebootest.

Messung ist also Real.

unter assignedIDs hinzugefügt, aber nicht beim hmlan entfernt.

genau. Entfernen wird aktuell nicht unterstützt.

ausserdem erscheinen grundsätzlich die virtuellen devices gar nicht. wäre schön, wenn dem so wär.

warum sollten die? Das HMLAN wird nie an ein Virtuelles Device senden. Es darf nicht assigned werden - Nicht mit dieser Semantik. HMLAN kennt das virtuelle Device nicht, es sendet "einfach so".
Es wäre also eine andere Variable...
Achtung: Assignen ist kontext-sensitiv verwendet. Das Assignen IM HMLAN ist FHEM "intern".

schade, dass beim cul keine assignedIDs zu sehen sind.

ist eine andere Baustelle... CUL gehört Rudi... vielleicht mache ich einmal einen Vorschlag.

aber wie du bereits zu logIDs gesagt hast, ist das nicht deine baustelle.

nun ja - fast. Ich müsste es bauen und Rudi vorlegen.

ersatzweise wäre die ausgabe einer tabelle mit zb "get assignedIDReport" sehr komfortabel, aus der sehr übersichtlich zu entnehmen ist, welches io mit welchem device assigned ist.

Code Auswählen Erweitern

get hm param -d IODev
ok? - hmmm...  nicht nach IO sortiert.

der absolute knüller wäre natürlich statt der kreuzchen zb radio-buttons, um die einstellungen der ioDev der hm-devices gleich zentral und komfortabel ändern (managen) zu können.

klar.
Es müsste meiner Ansicht nach etwas am Konzept geändert werden - um IO-switching zu unterstützen. Die vccu sehe ich hier als schlüssel, als schalt - oder zumindest als Konfigurationszentrale. Wenn ein User die vccu nutzt habe ich einen direkteren Zugriff auf IOs - die muss man sonst "suchen". Die vccu sollte dann die Assignments verwalten und schalten. Da könnte man dann auch die Tabelle einbauen.
Ein Device müsste der vccu assigned werden, damit diese es verwalten soll. Ich bin kein Freund von "suchen" wer gehört zu mir...

mal sehen...

aber ein entsprechendes reading prot_keepAlive hat es noch nicht gegeben

USB ist wohl nicht so anfällig

highload, overload: wird wohl vom hmusb nicht unterstützt?

Ich denke schon - HM hat die SW nach standart entwickelt, und der schreibt es vor. Der CUL ist der Standart wurscht - also nicht erwischen lassen. Aber ich besitze keins zum Testen.
Definieren ein Device mit attr Model "...RT...". Dann sende burstXmit - nach 30 Versuchen sollte ein Overload kommen

msgparsedelay: geben die raw-messages wohl nicht her?

nicht? Kannst du einmal rohmessages schicken? FHEM  (HMLAN) kennt keinen Unterschied...

mit 2 oder mehr io könnte man doch auch über eine direkte sendeüberwachung der io nachdenken. dann wüsste man bei cul und hmusb auch, wenn das senden eingestellt ist.

das mache ich wohl eher nicht. Wenn HMLAN das Senden einstellt bekommst du ein Reading. Generell bekommst du kein ACK. Das andere ist sehr aufwändig.... und nicht der security Level, den FHEM sieht.

durch set ccu update bekomme ich zwar unter internals STATE einen status der 3 io angezeigt, wohl aber nur, weil die internals werte sich nicht selber aktualisieren. was bedeuted info cleared?

Mal sehen.
Info Cleared ist. wenn du mit "clear" die protokoll-variablen löschst.
ccu ist (noch) ein Device - ohne Channel. Also ist State identisch mit protoState. Das kann so nicht bleiben....

Gruss Martin

[frank]

hallo martin,

Aktuell kannst du nur unassignen, wenn du das HMLAN rebootest.

stecker ziehen? wie sonst rebooten?

ausserdem erscheinen grundsätzlich die virtuellen devices gar nicht. wäre schön, wenn dem so wär.

warum sollten die?

beispiel realer vd, virtueller tc.
ich hatte am vd attr ioDev=hmusb gesetzt, um die kommunikation zum vd über den hmusb zu tätigen. ein blick ins log hat dann gezeigt, dass dadurch nur der direkte funk zum vd über den hmusb ging (getconfig, register setzen ...). die kommunikation vom vtc wurde weiterhin über hmlan getätigt. entsprechend der einstellung attr ioDev=hmlan am vtc. deshalb der wunsch die virtuellen tc unter assignedIDs im ioDev zu erfassen. erst das zusätzliche umschalten am vtc auf ioDev=hmusb führt nun dazu, dass jeglicher funkverkehr zum vd über den hmusb abgewickelt wird. oder man müsste mit realen devices gepeerte virtuelle devices automatisch mit dem attribut des realen devices verknüpfen.

msgparsedelay: geben die raw-messages wohl nicht her?

nicht? Kannst du einmal rohmessages schicken? FHEM  (HMLAN) kennt keinen Unterschied...

Code Auswählen Erweitern

2014.05.04 17:33:20.314 0: HMLAN_Send:  hmusb1 I:K
2014.05.04 17:33:20.354 0: HMLAN_Parse: hmusb1 V:03BC sNo:JEQ0121054 d:1ACE1F O:123ABC t:02DF47B7 IDcnt:0004
2014.05.04 17:33:40.329 0: HMLAN_Send:  hmusb1 S:SC7DE8685 stat:  00 t:00000000 d:01 r:C7DE8685 m:C1 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 17:33:40.505 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:035F002A d:FF r:FFC0     m:C1 A258 1DFDA5 D2D2D2 0000
2014.05.04 17:33:40.518 0: HMLAN_Parse: hmlan1 R:ED2D2D2   stat:0000 t:035F00C2 d:FF r:FFE6     m:C1 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 17:33:40.594 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:02DF9575 d:FF r:FFC0     m:C1 A258 1DFDA5 D2D2D2 0000
2014.05.04 17:33:40.608 0: HMLAN_Parse: hmusb1 R:RC7DE8685 stat:0002 t:00000000 d:FF r:7FFF     m:C1 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 17:33:45.324 0: HMLAN_Send:  hmusb1 I:K
2014.05.04 17:33:45.377 0: HMLAN_Parse: hmusb1 V:03BC sNo:JEQ0121054 d:1ACE1F O:123ABC t:02DFA977 IDcnt:0004
2014.05.04 17:33:47.336 0: HMLAN_Send:  hmusb1 S:SC7DEA1E4 stat:  00 t:00000000 d:01 r:C7DEA1E4 m:48 8002 D4D4D4 1BF81B 0101700000
2014.05.04 17:33:47.502 0: HMLAN_Parse: hmlan1 R:E1BF81B   stat:0000 t:035F1B8A d:FF r:FFD2     m:48 A258 1BF81B D4D4D4 008F
2014.05.04 17:33:47.515 0: HMLAN_Parse: hmlan1 R:ED4D4D4   stat:0000 t:035F1C23 d:FF r:FFE6     m:48 8002 D4D4D4 1BF81B 0101700000
2014.05.04 17:33:47.589 0: HMLAN_Parse: hmusb1 R:E1BF81B   stat:0000 t:02DFB0D4 d:FF r:FFC6     m:48 A258 1BF81B D4D4D4 008F
2014.05.04 17:33:47.603 0: HMLAN_Parse: hmusb1 R:RC7DEA1E4 stat:0002 t:00000000 d:FF r:7FFF     m:48 8002 D4D4D4 1BF81B 0101700000

highload, overload: wird wohl vom hmusb nicht unterstützt?

Ich denke schon - HM hat die SW nach standart entwickelt, und der schreibt es vor.

ich habe den hmusb gestern schon gequält. das senden hat er auch eingestellt. habe ich über hmlan festgestellt. es gab nur keine readings, oder andere hinweise. die raw-messages vom hmusb wurden weiterhin gelogged. also "hmlan_send"- und "hmlan_parse"-einträge. msgloadest ging bis über 150%.

mal sehen...

das hört sich vielversprechend an. dann will ich nicht weiter stören ... .

gruss frank

[martinp876]

stecker ziehen? wie sonst rebooten?

ja

die kommunikation vom vtc wurde weiterhin über hmlan getätigt.

hm - ja. Zum Senden muss in diesem Fall das vtc genommen werden - sonst würden wir auf VD wakeup warten. Das passiert nicht. Die Zentrale sucht das genutzte IO device selbständig aus -und leitet es vom VTC ab, nicht vom VD.
Eine Umstellung ist "nicht billig".
Ist ein Sonderfall...

ich habe den hmusb gestern schon gequält.

logge doch einmal - der status ist dann interessant, den das HMUSB rückliefert.

Gruss Martin