AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

fhemfreund

Zitat von: vbs am 03 April 2019, 12:58:45
...
Wenn ich zB "getConfig" mache, dann bekomme ich "Pending Message", die jedoch nie verarbeitet werden. Ich hätte gedacht, dass (ohne Burst) diese Messages bei der nächsten Kontaktaufnahem, also beim nächsten Senden, abgearbeitet werden. Ist aber nicht der Fall bei mir.
Erst wenn ich den Taster am Gerät drücke, dann wird offenbar genau eine Pending-Nachricht verarbeitet. Ich muss also mehrfalls drücken, um die Queue zu leeren. Kenne ich eigentlich bei HM-Sensoren anders. Ist das ein normales Verhalten oder geht da etwas schief?
...

Ist bei mir auch so. Sprich mit einem GetConfig + mehrmaligen Drücken des Tasters (sobald er auf Pending steht) wird dann die Config eingelesen.

Andreas

Tom Major

Das Verhalten bei der Übernahme von Config Änderungen habe ich hier mal versucht zu dokumentieren:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L183
Die Kommentare zu BIDI und BCAST.

Zitat
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).

Man kann das auf immer BIDI ändern wenn man will, dann wird es beim nächsten wakeup ohne Taster automatisch übernommen, zum Preis von leicht erhöhtem Funkverkehr wegen ACK.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

vbs

Ok danke, dann ist das ja ok soweit. Ich hab das probiert mit "BIDI" und es wird dann automatisch geholt. Danke!

SirBen

Moin,
ich habe ein HM-LC-BL1-FM nachgebaut und an dem Example von der Asksin++ Library natürlich die Device ID und Device Serial geändert, außerdem noch für die Relais alle High und Low invertiert (habe active LOW Relais Module).
An sich funktioniert alles, nur ist manchmal der Wert "pct" auf "0" obwohl er anders sein sollte.
Mir ist aufgefallen, dass im Log direkt vor dem falschen pct-Wert der Aktor anscheinend einen Neustart durchführt und somit standardmäßig "0" angenommen wird.
Von dem Neustart merkt man nichts. Er tritt bisher immer nur dann auf, wenn der Rolladen geöffnet werden soll. Er fährt auch ohne Probleme komplett auf.
Hier mal der Auszug aus dem Log vom Device:
2019-04-10_07:08:39 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-10_07:08:39 HM_220301 level: 100
2019-04-10_07:08:39 HM_220301 motor: stop:on
2019-04-10_07:08:39 HM_220301 pct: 100
2019-04-10_07:08:39 HM_220301 on
2019-04-10_07:08:39 HM_220301 timedOn: off
2019-04-10_20:19:31 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-10_20:19:31 HM_220301 level: 0
2019-04-10_20:19:31 HM_220301 motor: stop:off
2019-04-10_20:19:31 HM_220301 pct: 0
2019-04-10_20:19:31 HM_220301 off
2019-04-10_20:19:31 HM_220301 timedOn: off
2019-04-11_07:41:47 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_07:41:47 HM_220301 level: 0
2019-04-11_07:41:47 HM_220301 motor: stop:off
2019-04-11_07:41:47 HM_220301 pct: 0
2019-04-11_07:41:47 HM_220301 powerOn: 2019-04-11 07:41:47
2019-04-11_07:41:47 HM_220301 off
2019-04-11_07:41:47 HM_220301 timedOn: off
2019-04-11_09:12:24 HM_220301 level: set_100
2019-04-11_09:12:24 HM_220301 set_100
2019-04-11_09:12:24 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_09:12:24 HM_220301 level: 0
2019-04-11_09:12:24 HM_220301 motor: stop:off
2019-04-11_09:12:24 HM_220301 pct: 0
2019-04-11_09:12:24 HM_220301 off
2019-04-11_09:12:24 HM_220301 timedOn: running
2019-04-11_09:12:58 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_09:12:58 HM_220301 level: 100
2019-04-11_09:12:58 HM_220301 motor: stop:on
2019-04-11_09:12:58 HM_220301 pct: 100
2019-04-11_09:12:58 HM_220301 on
2019-04-11_09:12:58 HM_220301 timedOn: off
2019-04-11_12:13:46 HM_220301 level: set_5
2019-04-11_12:13:46 HM_220301 set_5
2019-04-11_12:13:47 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_12:13:47 HM_220301 level: 100
2019-04-11_12:13:47 HM_220301 motor: stop:on
2019-04-11_12:13:47 HM_220301 pct: 100
2019-04-11_12:13:47 HM_220301 on
2019-04-11_12:13:47 HM_220301 timedOn: running
2019-04-11_12:14:14 HM_220301 deviceMsg: 5 (to nanoCUL)
2019-04-11_12:14:14 HM_220301 level: 5
2019-04-11_12:14:14 HM_220301 motor: stop:5
2019-04-11_12:14:14 HM_220301 pct: 5
2019-04-11_12:14:14 HM_220301 5
2019-04-11_12:14:14 HM_220301 timedOn: off
2019-04-11_13:49:19 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_13:49:19 HM_220301 level: 100
2019-04-11_13:49:19 HM_220301 motor: stop:on
2019-04-11_13:49:19 HM_220301 pct: 100
2019-04-11_13:49:19 HM_220301 on
2019-04-11_13:49:19 HM_220301 timedOn: off
2019-04-11_20:19:53 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_20:19:53 HM_220301 level: 0
2019-04-11_20:19:53 HM_220301 motor: stop:off
2019-04-11_20:19:53 HM_220301 pct: 0
2019-04-11_20:19:53 HM_220301 off
2019-04-11_20:19:53 HM_220301 timedOn: off
2019-04-12_07:40:04 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_07:40:04 HM_220301 level: 0
2019-04-12_07:40:04 HM_220301 motor: stop:off
2019-04-12_07:40:04 HM_220301 pct: 0
2019-04-12_07:40:04 HM_220301 powerOn: 2019-04-12 07:40:04
2019-04-12_07:40:04 HM_220301 off
2019-04-12_07:40:04 HM_220301 timedOn: off
2019-04-12_11:19:53 HM_220301 set_on
2019-04-12_11:19:53 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:19:53 HM_220301 level: 0
2019-04-12_11:19:53 HM_220301 motor: stop:off
2019-04-12_11:19:53 HM_220301 pct: 0
2019-04-12_11:19:53 HM_220301 off
2019-04-12_11:19:53 HM_220301 timedOn: running
2019-04-12_11:20:28 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:20:28 HM_220301 level: 0
2019-04-12_11:20:28 HM_220301 motor: stop:off
2019-04-12_11:20:28 HM_220301 pct: 0
2019-04-12_11:20:28 HM_220301 off
2019-04-12_11:20:28 HM_220301 timedOn: off
2019-04-12_11:20:58 HM_220301 level: set_100
2019-04-12_11:20:58 HM_220301 set_100
2019-04-12_11:20:59 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:20:59 HM_220301 level: 0
2019-04-12_11:20:59 HM_220301 motor: stop:off
2019-04-12_11:20:59 HM_220301 pct: 0
2019-04-12_11:20:59 HM_220301 off
2019-04-12_11:20:59 HM_220301 timedOn: running
2019-04-12_11:21:35 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:21:35 HM_220301 level: 0
2019-04-12_11:21:35 HM_220301 motor: stop:off
2019-04-12_11:21:35 HM_220301 pct: 0
2019-04-12_11:21:35 HM_220301 off
2019-04-12_11:21:35 HM_220301 timedOn: off
2019-04-12_11:22:01 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:22:01 HM_220301 level: 0
2019-04-12_11:22:01 HM_220301 motor: stop:off
2019-04-12_11:22:01 HM_220301 pct: 0
2019-04-12_11:22:01 HM_220301 off
2019-04-12_11:22:01 HM_220301 timedOn: off
2019-04-12_11:22:52 HM_220301 set_on
2019-04-12_11:22:52 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:22:52 HM_220301 level: 0
2019-04-12_11:22:52 HM_220301 motor: stop:off
2019-04-12_11:22:52 HM_220301 pct: 0
2019-04-12_11:22:52 HM_220301 off
2019-04-12_11:22:52 HM_220301 timedOn: running
2019-04-12_11:23:27 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:23:27 HM_220301 level: 0
2019-04-12_11:23:27 HM_220301 motor: stop:off
2019-04-12_11:23:27 HM_220301 pct: 0
2019-04-12_11:23:27 HM_220301 powerOn: 2019-04-12 11:23:27
2019-04-12_11:23:27 HM_220301 off
2019-04-12_11:23:27 HM_220301 timedOn: off
2019-04-12_11:23:59 HM_220301 set_on
2019-04-12_11:24:00 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:24:00 HM_220301 level: 0
2019-04-12_11:24:00 HM_220301 motor: stop:off
2019-04-12_11:24:00 HM_220301 pct: 0
2019-04-12_11:24:00 HM_220301 off
2019-04-12_11:24:00 HM_220301 timedOn: running
2019-04-12_11:24:33 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-12_11:24:33 HM_220301 level: 100
2019-04-12_11:24:33 HM_220301 motor: stop:on
2019-04-12_11:24:33 HM_220301 pct: 100
2019-04-12_11:24:33 HM_220301 on
2019-04-12_11:24:33 HM_220301 timedOn: off


und hier aus dem FHEM Log:
2019.04.11 09:12:24 3: CUL_HM set HM_220301 pct 100
2019.04.11 12:13:46 3: CUL_HM set HM_220301 pct 5
2019.04.12 11:19:53 3: CUL_HM set HM_220301 on
2019.04.12 11:20:58 3: CUL_HM set HM_220301 pct 100
2019.04.12 11:22:01 3: CUL_HM set HM_220301 statusRequest
2019.04.12 11:22:23 3: CUL_HM set HM_220301 getConfig
2019.04.12 11:22:52 3: CUL_HM set HM_220301 on
2019.04.12 11:23:59 3: CUL_HM set HM_220301 on


Hier das list vom Device:
Internals:
   DEF        220301
   FUUID      5c850f3f-f33f-2b06-52b6-3fe19a17ee2a0571
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     62
   NAME       HM_220301
   NOTIFYDEV  global
   NR         65
   NTFY_ORDER 50-HM_220301
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:02 - t:10 s:220301 d:310388 0601C80048
   nanoCUL_MSGCNT 62
   nanoCUL_RAWMSG A0E02A2102203013103880601C80048::-76:nanoCUL
   nanoCUL_RSSI -76
   nanoCUL_TIME 2019-04-12 11:24:33
   peerList   self01,self02,
   protLastRcv 2019-04-12 11:24:33
   protRcv    61 last_at:2019-04-12 11:24:33
   protResnd  1 last_at:2019-04-09 12:27:23
   protSnd    61 last_at:2019-04-12 11:24:33
   protState  CMDs_done
   rssi_at_nanoCUL cnt:62 min:-81.5 max:-72 avg:-75.95 lst:-76
   rssi_nanoCUL cnt:27 min:-106 max:-72 avg:-77.22 lst:-72
   READINGS:
     2019-04-12 11:24:00   CommandAccepted yes
     2019-04-09 09:24:27   D-firmware      2.4
     2019-04-09 09:24:27   D-serialNr      RolloKind3
     2019-04-12 11:22:24   PairedTo        0x310388
     2019-04-08 12:22:03   R-confBtnTime   5 min
     2019-04-08 12:23:27   R-driveDown     26.5 s
     2019-01-16 11:08:32   R-driveTurn     0.5 s
     2019-04-08 12:23:27   R-driveUp       29 s
     2019-04-09 09:25:11   R-intKeyVisib   invisib
     2019-04-08 12:22:03   R-localResDis   off
     2019-04-09 09:25:11   R-pairCentral   0x310388
     2019-01-16 11:08:32   R-refRunCounter 0
     2019-01-16 11:08:34   R-self01-lgActionType jmpToTarget
     2019-01-16 11:08:34   R-self01-lgBlJtDlyOff refOff
     2019-01-16 11:08:34   R-self01-lgBlJtDlyOn dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtOff dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtOn dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtRampOff rampOff
     2019-01-16 11:08:34   R-self01-lgBlJtRampOn on
     2019-01-16 11:08:34   R-self01-lgBlJtRefOff rampOff
     2019-01-16 11:08:34   R-self01-lgBlJtRefOn on
     2019-01-16 11:08:34   R-self01-lgCtDlyOff geLo
     2019-01-16 11:08:34   R-self01-lgCtDlyOn geLo
     2019-01-16 11:08:34   R-self01-lgCtOff geLo
     2019-01-16 11:08:34   R-self01-lgCtOn geLo
     2019-01-16 11:08:34   R-self01-lgCtRampOff geLo
     2019-01-16 11:08:34   R-self01-lgCtRampOn geLo
     2019-01-16 11:08:34   R-self01-lgCtRefOff geLo
     2019-01-16 11:08:34   R-self01-lgCtRefOn geLo
     2019-01-16 11:08:34   R-self01-lgCtValHi 100
     2019-01-16 11:08:34   R-self01-lgCtValLo 50
     2019-01-16 11:08:34   R-self01-lgDriveMode direct
     2019-01-16 11:08:34   R-self01-lgMaxTimeF 0.5 s
     2019-01-16 11:08:34   R-self01-lgMultiExec on
     2019-01-16 11:08:34   R-self01-lgOffDly 0 s
     2019-01-16 11:08:34   R-self01-lgOffLevel 0 %
     2019-01-16 11:08:34   R-self01-lgOffTime unused
     2019-01-16 11:08:34   R-self01-lgOffTimeMode absolut
     2019-01-16 11:08:34   R-self01-lgOnDly 0 s
     2019-01-16 11:08:34   R-self01-lgOnLevel 100 %
     2019-01-16 11:08:34   R-self01-lgOnTime unused
     2019-01-16 11:08:34   R-self01-lgOnTimeMode absolut
     2019-01-16 11:08:34   R-self01-shActionType jmpToTarget
     2019-01-16 11:08:34   R-self01-shBlJtDlyOff refOff
     2019-01-16 11:08:34   R-self01-shBlJtDlyOn dlyOff
     2019-01-16 11:08:34   R-self01-shBlJtOff dlyOff
     2019-01-16 11:08:34   R-self01-shBlJtOn dlyOff
     2019-04-08 12:22:05   R-self01-shBlJtRampOff rampOff
     2019-04-08 11:59:45   R-self01-shBlJtRampOn on
     2019-01-16 11:08:34   R-self01-shBlJtRefOff rampOff
     2019-01-16 11:08:34   R-self01-shBlJtRefOn on
     2019-01-16 11:08:34   R-self01-shCtDlyOff geLo
     2019-01-16 11:08:34   R-self01-shCtDlyOn geLo
     2019-01-16 11:08:34   R-self01-shCtOff geLo
     2019-01-16 11:08:34   R-self01-shCtOn geLo
     2019-01-16 11:08:34   R-self01-shCtRampOff geLo
     2019-01-16 11:08:34   R-self01-shCtRampOn geLo
     2019-01-16 11:08:34   R-self01-shCtRefOff geLo
     2019-01-16 11:08:34   R-self01-shCtRefOn geLo
     2019-01-16 11:08:34   R-self01-shCtValHi 100
     2019-01-16 11:08:34   R-self01-shCtValLo 50
     2019-01-16 11:08:34   R-self01-shDriveMode direct
     2019-01-16 11:08:34   R-self01-shMaxTimeF unused
     2019-01-16 11:08:34   R-self01-shMultiExec off
     2019-01-16 11:08:34   R-self01-shOffDly 0 s
     2019-01-16 11:08:34   R-self01-shOffLevel 0 %
     2019-01-16 11:08:34   R-self01-shOffTime unused
     2019-01-16 11:08:34   R-self01-shOffTimeMode absolut
     2019-01-16 11:08:34   R-self01-shOnDly 0 s
     2019-01-16 11:08:34   R-self01-shOnLevel 100 %
     2019-01-16 11:08:34   R-self01-shOnTime unused
     2019-01-16 11:08:34   R-self01-shOnTimeMode absolut
     2019-01-16 11:08:35   R-self02-lgActionType jmpToTarget
     2019-01-16 11:08:35   R-self02-lgBlJtDlyOff dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtDlyOn refOn
     2019-01-16 11:08:35   R-self02-lgBlJtOff dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtOn dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtRampOff off
     2019-01-16 11:08:35   R-self02-lgBlJtRampOn rampOn
     2019-01-16 11:08:35   R-self02-lgBlJtRefOff off
     2019-01-16 11:08:35   R-self02-lgBlJtRefOn rampOn
     2019-01-16 11:08:35   R-self02-lgCtDlyOff geLo
     2019-01-16 11:08:35   R-self02-lgCtDlyOn geLo
     2019-01-16 11:08:35   R-self02-lgCtOff geLo
     2019-01-16 11:08:35   R-self02-lgCtOn geLo
     2019-01-16 11:08:35   R-self02-lgCtRampOff geLo
     2019-01-16 11:08:35   R-self02-lgCtRampOn geLo
     2019-01-16 11:08:35   R-self02-lgCtRefOff geLo
     2019-01-16 11:08:35   R-self02-lgCtRefOn geLo
     2019-01-16 11:08:35   R-self02-lgCtValHi 100
     2019-01-16 11:08:35   R-self02-lgCtValLo 50
     2019-01-16 11:08:35   R-self02-lgDriveMode direct
     2019-01-16 11:08:35   R-self02-lgMaxTimeF 0.5 s
     2019-01-16 11:08:35   R-self02-lgMultiExec on
     2019-01-16 11:08:35   R-self02-lgOffDly 0 s
     2019-01-16 11:08:35   R-self02-lgOffLevel 0 %
     2019-01-16 11:08:35   R-self02-lgOffTime unused
     2019-01-16 11:08:35   R-self02-lgOffTimeMode absolut
     2019-01-16 11:08:35   R-self02-lgOnDly 0 s
     2019-01-16 11:08:35   R-self02-lgOnLevel 100 %
     2019-01-16 11:08:35   R-self02-lgOnTime unused
     2019-01-16 11:08:35   R-self02-lgOnTimeMode absolut
     2019-01-16 11:08:35   R-self02-shActionType jmpToTarget
     2019-01-16 11:08:35   R-self02-shBlJtDlyOff dlyOn
     2019-01-16 11:08:35   R-self02-shBlJtDlyOn refOn
     2019-01-16 11:08:35   R-self02-shBlJtOff dlyOn
     2019-01-16 11:08:35   R-self02-shBlJtOn dlyOn
     2019-04-08 11:59:46   R-self02-shBlJtRampOff off
     2019-04-08 12:22:06   R-self02-shBlJtRampOn rampOn
     2019-01-16 11:08:35   R-self02-shBlJtRefOff off
     2019-01-16 11:08:35   R-self02-shBlJtRefOn rampOn
     2019-01-16 11:08:35   R-self02-shCtDlyOff geLo
     2019-01-16 11:08:35   R-self02-shCtDlyOn geLo
     2019-01-16 11:08:35   R-self02-shCtOff geLo
     2019-01-16 11:08:35   R-self02-shCtOn geLo
     2019-01-16 11:08:35   R-self02-shCtRampOff geLo
     2019-01-16 11:08:35   R-self02-shCtRampOn geLo
     2019-01-16 11:08:35   R-self02-shCtRefOff geLo
     2019-01-16 11:08:35   R-self02-shCtRefOn geLo
     2019-01-16 11:08:35   R-self02-shCtValHi 100
     2019-01-16 11:08:35   R-self02-shCtValLo 50
     2019-01-16 11:08:35   R-self02-shDriveMode direct
     2019-01-16 11:08:35   R-self02-shMaxTimeF unused
     2019-01-16 11:08:35   R-self02-shMultiExec off
     2019-01-16 11:08:35   R-self02-shOffDly 0 s
     2019-01-16 11:08:35   R-self02-shOffLevel 0 %
     2019-01-16 11:08:35   R-self02-shOffTime unused
     2019-01-16 11:08:35   R-self02-shOffTimeMode absolut
     2019-01-16 11:08:35   R-self02-shOnDly 0 s
     2019-01-16 11:08:35   R-self02-shOnLevel 100 %
     2019-01-16 11:08:35   R-self02-shOnTime unused
     2019-01-16 11:08:35   R-self02-shOnTimeMode absolut
     2019-01-16 11:08:32   R-sign          off
     2019-01-16 11:08:32   R-statusInfoMinDly 2 s
     2019-01-16 11:08:32   R-statusInfoRandom 1 s
     2019-01-16 11:08:32   R-transmitTryMax 6
     2019-04-12 11:22:23   RegL_00.         00:00 02:01 0A:31 0B:03 0C:88 15:05 18:00
     2019-04-12 11:22:24   RegL_01.         00:00 08:00 0B:01 0C:09 0D:01 0E:22 0F:05 10:00 30:06 57:24
     2019-04-12 11:22:25   RegL_03.self01   00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0F:00 11:C8 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8F:00 91:C8 9C:00 9D:05 9E:93 9F:00
     2019-04-12 11:22:27   RegL_03.self02   00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0F:00 11:C8 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8F:00 91:C8 9C:00 9D:05 9E:68 9F:00
     2019-04-12 11:24:33   deviceMsg       on (to nanoCUL)
     2019-04-12 11:24:33   level           100
     2019-04-12 11:24:33   motor           stop:on
     2019-04-12 11:24:33   pct             100
     2019-04-12 11:22:24   peerList        self01,self02,
     2019-04-12 11:23:27   powerOn         2019-04-12 11:23:27
     2019-04-12 11:24:33   recentStateType info
     2019-04-12 11:24:33   state           on
     2019-04-12 11:24:33   timedOn         off
   helper:
     HM_CMDNR   2
     PONtest    0
     cSnd       113103882203010201C80000,113103882203010201C80000
     dlvlCmd    ++A0113103882203010201C80000
     mId        0005
     peerFriend peerSens,peerVirt
     peerIDsRaw ,22030101,22030102,00000000
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +220301,00,00,00
       nextSend   1555061073.72008
       prefIO     
       rxt        0
       vccu       
       p:
         220301
         00
         00
         00
     mRssi:
       mNo        02
       io:
         nanoCUL:
           -74
           -74
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         nanoCUL
       flg        A
       ts         1555061073.62327
       ack:
         HASH(0x1d05008)
         02800231038822030100
     rssi:
       at_nanoCUL:
         avg        -75.9516129032258
         cnt        62
         lst        -76
         max        -72
         min        -81.5
       nanoCUL:
         avg        -77.2222222222222
         cnt        27
         lst        -72
         max        -72
         min        -106
     shadowReg:
     tmpl:
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     251_anything
   firmware   2.4
   genericDeviceType blind
   model      HM-LC-BL1-FM
   peerIDs    00000000,22030101,22030102,
   room       Tobi,CUL_HM,Homebridge
   serialNr   RolloKind3
   subType    blindActuator
   webCmd     statusRequest:toggleDir:on:off:up:down:stop


Ich habe am Aktor 2 Taster angeschlossen für die manuelle Bedienung. Diese sind auch active-Low, also beim Betätigen 0V, sonst 3.3V.

Hat jemand eine Ahnung woran das liegen kann? Bin ziemlich ratlos.
Ich bin doch bestimmt nicht der Einzige, der den Code von pa-pa benutz?!

Vielen Dank schon mal.
Gruß Ben

papa

Hm - aus den FHEM-Logs sieht man nicht wirklich was. Kannst Du mal an der seriellen Konsole am Geräte mitloggen ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

SirBen

Das Gerät ist im Rolladenkasten eingebaut. Komme da nicht so leicht ran.
Eventuell könnte ich einfach noch einen Rolladen umrüsten und prüfen, ob dort das gleiche Problem auftritt.
könnte aber ein paar Tage dauern...

SirBen

#1236
Moin,
mir ist heute noch was aufgefallen. Heute morgen ist der Rolladen mit dem Taster angesteuert geöffnet worden (kurz vor dem ersten Log Eintrag). Das Feedback vom Aktor an FHEM war wieder "0".
Danach habe ich den "on" Befehl von FHEM an den Aktor gesendet und nach 36 Sekunden kommt wieder die Position "0" vom Aktor.
Nach einem erneuten Versuch den Rolladen auf 100% zu setzen mittels FHEM kommt 34 Sekunden später die Antwort, dass er endlich auf 100% steht (also open).
Die Fahrzeit ist fürs Öffnen mit 29 Sekunden hinterlegt.

Hier mal die LOG Auszüge:
2019-04-15_07:32:14 HM_220301 level: 0
2019-04-15_07:32:14 HM_220301 motor: stop:off
2019-04-15_07:32:14 HM_220301 pct: 0
2019-04-15_07:32:14 HM_220301 powerOn: 2019-04-15 07:32:14
2019-04-15_07:32:14 HM_220301 off
2019-04-15_07:32:14 HM_220301 timedOn: off
2019-04-15_10:18:39 HM_220301 set_on
2019-04-15_10:18:39 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_10:18:39 HM_220301 level: 0
2019-04-15_10:18:39 HM_220301 motor: stop:off
2019-04-15_10:18:39 HM_220301 pct: 0
2019-04-15_10:18:39 HM_220301 off
2019-04-15_10:18:39 HM_220301 timedOn: running
2019-04-15_10:19:15 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_10:19:15 HM_220301 level: 0
2019-04-15_10:19:15 HM_220301 motor: stop:off
2019-04-15_10:19:15 HM_220301 pct: 0
2019-04-15_10:19:15 HM_220301 off
2019-04-15_10:19:15 HM_220301 timedOn: off
2019-04-15_12:52:49 HM_220301 level: set_100
2019-04-15_12:52:49 HM_220301 set_100
2019-04-15_12:52:49 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_12:52:49 HM_220301 level: 0
2019-04-15_12:52:49 HM_220301 motor: stop:off
2019-04-15_12:52:49 HM_220301 pct: 0
2019-04-15_12:52:49 HM_220301 off
2019-04-15_12:52:49 HM_220301 timedOn: running
2019-04-15_12:53:23 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-15_12:53:23 HM_220301 level: 100
2019-04-15_12:53:23 HM_220301 motor: stop:on
2019-04-15_12:53:23 HM_220301 pct: 100
2019-04-15_12:53:23 HM_220301 on
2019-04-15_12:53:23 HM_220301 timedOn: off


Ich finde das seltsam...
Kann mir jemand die Log Einträge erklären? Was z.B. bedeutet "motor: stop:off" und "tidemOn: off"?

Danke und Gruß

papa

Hm - bei mir (original HM-LC-Bl1PBU-FM) entspricht 0 -> Offen und 100 -> Geschlossen. Ich denke, so funktioniert auch die Implementierung der AskSinPP.

Komisch ist, dass er bei "set on" scheinbar nach 0 fährt - auch wenn er schon da ist. Hast Du irgendwas im Code geändert ? Der serielle Log wäre hier wirklich hilfreich.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

SirBen

#1238
ZitatMoin,
ich habe ein HM-LC-BL1-FM nachgebaut und an dem Example von der Asksin++ Library natürlich die Device ID und Device Serial geändert, außerdem noch für die Relais alle High und Low invertiert (habe active LOW Relais Module).
An sich funktioniert alles, nur ist manchmal der Wert "pct" auf "0" obwohl er anders sein sollte.
Mir ist aufgefallen, dass im Log direkt vor dem falschen pct-Wert der Aktor anscheinend einen Neustart durchführt und somit standardmäßig "0" angenommen wird.
Von dem Neustart merkt man nichts. Er tritt bisher immer nur dann auf, wenn der Rolladen geöffnet werden soll. Er fährt auch ohne Probleme komplett auf.

Moin,
ich habe es heute geschafft, ein bisschen mehr Fehlersuche zu betreiben.
Mit angeschlossenem FTDI USB to Serial Adapter funktioniert die Steuerung ohne Fehler.  :o
Ich habe mindestens 20 mal verschiedene Stellungen angefahren.
Kaum war der Adapter getrennt, schon nach dem zweiten Fahrvorgang ein reboot.
Für mich klingt das nach einem Problem der Spannungsversorgung.
Versorgt wird das Gerät von einem HiLink 5V 3W Modul.
Die 3.3V nehme ich direkt am pro mini ab und benötige diese für das CC1101 Modul und die Optokoppler Schaltung für die Taster und das Relais Modul.
Meine Vermutung liegt in der 3.3V Versorgung. Eventuell wird diese zu lange zu stark belastet, dass für den pro mini nicht mehr genügend Leistung übrig ist und ein Neustart erfolgt.
Könnte das eine Erklärung sein? Oder bin ich dort total auf dem Holzweg?
Ich bin über jeden Denkanstoß dankbar.
Gruß Ben

Edit: Ich habe noch weiter recherchiert. Es könnte wirklich was dran sein an der Spannungsversorgung:
http://tips-und-mehr.de/cul-selbstbau-spannungstechnisch-auf-der-sicheren-seite/
Man beachte den Kommentar von Dirk Anderseck.
Somit werde ich (sobald es meine Zeit zulässt) einen Kondensator zusätzlich einbauen. Ich werde berichten...

papa

Das kann schon sein, aber ohne Schaltplan kann man da nichts sagen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

SirBen

Moin,
eine kurze Rückmeldung: es lag am fehlenden Kondensator.
Ich habe die 3,3V Spannungsversorgung für das CC1101 Modul mit einem 100uF Kondensator erweitert (vielleicht reichen auch 10uF) und jetzt funktioniert die Schaltung fehlerfrei.
@papa
Wenn du möchtest, kannst du das gerne auf GitHub oder deiner sehr gut gelungenen asksin Seite aufmerken.
Vielleicht hilft das ja dem einen oder anderen.
Vielen Dank für die Bemühungen!
Gruß

MBHG

Hallo,

ich habe eine ganze Reihe von HM_SW4 Selbstbau Aktoren in Betrieb, alle mit AES. Alle sind vollstandig gepairt, HM info liefert keine offenen Punkte. An einem der Aktoren habe ich ein seltsames Problem:

Wenn ich den Aktor schalte, dann funktioniert alles prächtig. Er schaltet das Relais, die Bestätigung kommt. Nach ca 2 min schaltet der Aktor aber selbstständig auf off.

Ich habe den Aktor mehrfach neu beschrieben und gepairt. Immer das gleiche Verhalten. Die lists von den Aktoren sind bis auf IDs identisch.

HM_66815A ....  funktioniert nicht
HM_668159 ... funktioniert

Log
2019.05.07 07:12:06 3: CUL_HM set Sprinkler5 on
2019.05.07 07:12:07 3: CUL_HM set Sprinkler4 on
2019.05.07 07:12:08 4: CUL_HM_Resend: HM_66815A nr 2
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:2
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:1
2019.05.07 07:12:08 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:12:08 3: CUL_HM set Sprinkler3 on
2019.05.07 07:12:08 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:1
2019.05.07 07:12:09 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:09 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:09 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:0
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_done_Errors:1
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:12:09 3: CUL_HM set Sprinkler2 on
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:10 3: CUL_HM set Sprinkler1 on
2019.05.07 07:12:12 4: CUL_HM_Resend: HM_66815A nr 2
2019.05.07 07:12:12 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:12 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:12 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:0
2019.05.07 07:12:12 3: CUL_HM set Pump on
2019.05.07 07:12:12 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:12:13 4: CUL_HM_Resend: HM_668159 nr 2
2019.05.07 07:12:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:2
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:1
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:15 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:02 3: CUL_HM set Sprinkler3 on
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:02 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:02 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:12 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:12 3: CUL_HM set Sprinkler3 off
2019.05.07 07:15:12 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:13 3: CUL_HM set Sprinkler2 off
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:14 3: CUL_HM set Sprinkler1 off
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:15 3: CUL_HM set Pump off
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:15 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:15 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd  to authenticate
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_done


Hat jemand eine Idee?
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

papa

Mach mal nen RESET - und dann neu anlernen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

MBHG

Danke, hatte ich schon mehrfach gemacht. Ich habe es nach drei Tagen gerade gefunden: das passiert nur, wenn viele Aktoren an sind, dh viele Relais geschaltet sind. Anscheinend ist der USB Charger zu schwach und der HM_66815A macht einen Reset und sendet für alle Aktoren Status off. Der HM_668159 kommt wohl mit geringfügig weniger Spannung aus.

Danke für den Hinweis.

Marc


-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

papa

Sowas sollte man gut in den seriellen Ausgaben sehen. Das wäre meine nächste Frage gewesen :-)
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire