HM-SEC-SCo nach /etc/init.d/fhem stop/start kein state

Begonnen von xray, 13 Dezember 2016, 23:30:04

Vorheriges Thema - Nächstes Thema

xray

Hallo zusammen,

ich versuche gerade meinen ersten Homeatic Sensor (HM-SEC-SCo) in Kombination mit dem RPi-Modul (HM-MOD-RPI-PCB) zum Laufen zu bekommen und eigentlich klappt es auch schon ganz gut:
Nach erfolgreichem Pairing via set <CUL> hmPairForSec 600 und anschließendem Betätigen des Tasters am Sensor wurde das Device entsprechend in der fhem.cfg angelegt:

Zitatdefine HM_4E55BF CUL_HM 4E55BF
attr HM_4E55BF room CUL_HM
define FileLog_HM_4E55BF FileLog ./log/HM_4E55BF-%Y.log HM_4E55BF
attr FileLog_HM_4E55BF logtype text
attr FileLog_HM_4E55BF room CUL_HM

Das Pairing hat den Readings nach ebenfalls geklappt, zumindest soweit ich es einschätzen kann:

ZitatReadings
Activity alive 2016-12-13 23:09:14
CommandAccepted no 2016-12-13 21:39:09
D-firmware 1.0 2016-12-13 23:09:14
D-serialNr xxx 2016-12-13 23:09:14
R-pairCentral set_xxx 2016-12-13 21:38:39
RegL_00. 2016-12-13 23:11:15
aesCommToDev ok 2016-12-13 21:38:40
aesKeyNbr 00 2016-12-13 21:38:40
alive yes 2016-12-13 22:27:26
battery ok 2016-12-13 23:10:57
contact open (to RM_HmUART_EG) 2016-12-13 23:10:57
recentStateType info 2016-12-13 22:27:26
sabotageError on 2016-12-13 22:27:26
state RESPONSE TIMEOUT:RegisterRead 2016-12-13 23:11:01
trigDst_xxx noConfig 2016-12-13 23:12:07
trigger_cnt 73 2016-12-13 23:12:07

Der Sensor zeigt nun auch den state korrekt an.

ABER:
Sobald ich den fhem Service neu starte oder einen Reboot durchführe, werden nur noch die Readings trigDst_xxx  und trigger_cnt bei Änderungen des Schaltzustands geändert, der state bleibt unverändert.
Erst wenn ich den Taster am Sensor einmal kurz drücke und kurz warte, wird der state wieder korrekt übertragen. Warum ist dies so?

Hoffe, die Frage ist nicht zu trivial...

Grüße & Danke

xray

MadMax-FHEM

Hallo xray,

poste doch mal ein list CUL_HM 4E55BF in code Tags (# in der Menuleiste)...

Wie/nach welcher Anleitung hast du fhem installiert?
Auf welcher HW, also welcher PI?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Otto123

Hallo xray,

obwohl wie schon angesprochen ein list besser ist:
R-pairCentral set_xxx 2016-12-13 21:38:39
Heißt er ist noch nicht gepairt, da darf nicht set stehen, sondern nur xxxxxx.

Drück nochmal die Configtaste, es müssen noch Daten übertragen werden. Die LED muss danach unregelmäßig blinken.

Gruß Otto
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

xray

Hi Joachim,

vielen Dank für dein Feedback!

list CUL_HM 4E55BF
Liefert kein Ergebnis, vielleicht hilft ja ein list TYPE=CUL_HM:

Internals:
   DEF        4E55BF
   IODev      RM_HmUART_EG
   LASTInputDev RM_HmUART_EG
   MSGCNT     4
   NAME       HM_4E55BF
   NOTIFYDEV  global
   NR         513
   NTFY_ORDER 50-HM_4E55BF
   RM_HmUART_EG_MSGCNT 4
   RM_HmUART_EG_RAWMSG 0501004371A6414E55BF81Bxxx0151C8
   RM_HmUART_EG_RSSI -67
   RM_HmUART_EG_TIME 2016-12-13 23:53:39
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:71 - t:41 s:4E55BF d:81Bxxx 0151C8
   protLastRcv 2016-12-13 23:53:39
   protSnd    4 last_at:2016-12-13 23:53:39
   protState  CMDs_done
   rssi_at_RM_HmUART_EG lst:-67 max:-36 min:-67 avg:-45.75 cnt:4
   Readings:
     2016-12-13 23:53:39   trigDst_81Bxxx  noConfig
     2016-12-13 23:53:39   trigger_cnt     81
   Helper:
     HM_CMDNR   113
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4E55BF,00,00,00
       nextSend   1481669620.18334
       prefIO
       rxt        0
       vccu
       p:
         4E55BF
         00
         00
         00
     Mrssi:
       mNo        71
       Io:
         RM_HmUART_EG -65
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         RM_HmUART_EG
       flg        A
       ts         1481669619.8964
       ack:
         HASH(0x34971e0)
         71800281Bxxx4E55BF00
     Rssi:
       At_rm_hmuart_eg:
         avg        -45.75
         cnt        4
         lst        -67
         max        -36
         min        -67
Attributes:
   IODev      RM_HmUART_EG
   autoReadReg 4_reqStatus
   expert     2_raw
   room       CUL_HM


Meine CUL wurde wie folgt definiert:

define RM_HmUART_EG HMUARTLGW uart://192.168.1.40:2000
attr RM_HmUART_EG hmId 81Bxxx


Drücke ich den Taster am Sensor erscheint bei list TYPE=CUL_HM folgendes:

ActionDetector
HM_4E55BF


Ich habe auf einem RPi 1 Jessie installiert, gemäß Wiki das HM-MOD-RPI-PCB zum Laufen gebracht und den Zugriff via socat eingerichtet. Klappt soweit ja... :-)

Grüße

xray

xray

Hallo Otto,

ich habe nun erneut den Dienst gestoppt und gestartet.
Das Reading sieht nun wie folgt aus:
Activity alive 2016-12-14 00:01:35
D-firmware 1.0 2016-12-14 00:01:35
D-serialNr NEQ1941201 2016-12-14 00:01:35
battery ok 2016-12-14 00:02:00
contact open (to RM_HmUART_EG) 2016-12-14 00:02:00
state open 2016-12-14 00:02:00
trigDst_81Bxxx noConfig 2016-12-14 00:10:34
trigger_cnt 93 2016-12-14 00:10:34


"state" ändert sich aber immer noch erst, nachdem ich den Taster am Sensor gedrückt habe...

Grüße

xray

MadMax-FHEM

Zitat von: MadMax-FHEM am 13 Dezember 2016, 23:36:18
Hallo xray,

poste doch mal ein list CUL_HM 4E55BF in code Tags (# in der Menuleiste)...

Wie/nach welcher Anleitung hast du fhem installiert?
Auf welcher HW, also welcher PI?

Gruß, Joachim

Hi xray,

sorry falsches copy und falsches paste:

list HM_4E55BF

@Otto: stimmt. R-Pair-Central. Hatte ich in der "Übersicht" tatsächlich übersehen...

Den Dienst (damit meinst du fhem??) brauchst du nicht stoppen/starten.

Erst mal muss das Gerät komplett angelernt (gepaired) sein: R-Pair-Central bzw. PairedTo: dort muss deine HMID stehen OHNE set_

Wie Otto schon geschrieben hat:

einfach mal (öfter) den Config-Knopf beim Gerät kurz drücken, warten und evtl. noch mal drücken.

Die optischen Fensterkontakte brauchen immer etwas Geduld (zumindest bei mir)...
Wichtig: nur nicht hektisch werden, macht's nicht besser.

Nach einem (neuen) list sehen wir weiter.
Aber wahrscheinlich noch nicht komplett gepaired bzw. fehlen wohl noch ein paar Register die gelesen werden müssen (getConfig wird meist nach/beim Pairen autom. angestoßen und liest die vom Gerät aus).

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Otto123

Hallo xray,

irgendwie werden es immer weniger Readings?
Das verstehe ich gerade gar nicht.

Also wenn Du das mit dem list nicht hinbekommst: Wichtig ist es muss zwei Readings geben pairCentral und pairedTo da muss Deine hmId drin stehen, sonst ist nicht gepairt.

Was Du erzählst, dass der state sich nach dem Neustart von FHEM nicht mehr ändert, kann ich mir gar nicht erklären. Maximal so, dass Du kein Save Config machst, was aber autocreate eigentlich per default macht. Der Status vom Sensor wird übermittelt, egal ob gepairt oder nicht.
Aber klar wenn nach dem Neustart kein Device mehr da ist geht es natürlich nicht. Durch Configtaste drücken erzeugst Du wieder ein Device (nicht gepairt) und der Status wird wieder gezeigt.

Gruß Otto
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

xray

Hallo zusammen,

"list" ist kein Problem, das werde ich heute Abend hier posten können.

Die gesamte Problematik ist mir erst aufgefallen, als der Sensor nach einem Neustart von fhem (aufgrund Änderungen anderer Art in der fhem.cfg) nicht mehr funktioniert hat. Ich habe den Neustart nicht aufgrund des HM-Sensors durchgeführt.

Ich werde heute Abend mehrfach den Config-Button betätigen und das Verhalten beobachten.

Die Tatsache, dass es immer weniger Readings werden, der Sensor aber nach dem Betätigen der Config-Taste trotzdem funktioniert, kann ich mir leider ebenfalls nicht erklären.
Ein Save Config habe ich bisher manuell nicht angestoßen, da ich autocreate aktiviert habe.
Das Device selbst wird nach dem Neustart weiterhin in fhem angezeigt und auch der trigger_cnt zählt weiter hoch. Die "interessanten" Readings werden allerdings erst nach Betätigen des Config-Buttons aktualisiert.

Im Wiki wird auch ein Config check erwähnt:

define hm HMInfo
set hm configCheck


Kann mir dieser weiterhelfen?

Danke & Grüße

xray

MadMax-FHEM

#8
Zitat von: xray am 14 Dezember 2016, 11:17:38
Hallo zusammen,

"list" ist kein Problem, das werde ich heute Abend hier posten können.

...

Ich werde heute Abend mehrfach den Config-Button betätigen und das Verhalten beobachten.

Erst mal das "list" posten.
Ein wildes Drücken irgendwelcher Taster bringt nichts ohne zu wissen was los ist bzw. ob das Drücken was bringt/bringen kann...


Zitat von: xray am 14 Dezember 2016, 11:17:38
Die Tatsache, dass es immer weniger Readings werden, der Sensor aber nach dem Betätigen der Config-Taste trotzdem funktioniert, kann ich mir leider ebenfalls nicht erklären.

Wenn autocreate aktiv ist, dann versucht fhem aus allen empfangenen Funkmeldungen was zu machen...
Eine Anlernmeldung (Config drücken) vom Gerät führt dazu, dass fhem/autocreate wieder anlegt was anzulegen geht (bzw. fehlt).
Ich speichere allerdings trotz autocreate und autosave die Config nach allen (größeren) Änderungen manuell...
...sicher ist mal sicher.

Eigentlich sieht man ja am "roten Fragezeichen", ob was zu speichern wäre...


Zitat von: xray am 14 Dezember 2016, 11:17:38
Das Device selbst wird nach dem Neustart weiterhin in fhem angezeigt und auch der trigger_cnt zählt weiter hoch. Die "interessanten" Readings werden allerdings erst nach Betätigen des Config-Buttons aktualisiert.

Gleicher Grund: das Geräte ist irgendwie in fhem angelegt (heißt aber NICHT, dass schon gepaired ist!! Denn auch das Gerät muss diesem Pairing "zustimmen", das sind dann die erwähnten Register bzw. Readings [PairedTo / R-PairCentral]).
Fhem empfängt die Funksignale und kann sie ja dem angelegten Gerät zuordnen und tut dies auch: trigger count, offen, geschlossen, ...


Zitat von: xray am 14 Dezember 2016, 11:17:38
Im Wiki wird auch ein Config check erwähnt:

define hm HMInfo
set hm configCheck


Kann mir dieser weiterhelfen?

Auf jeden Fall mal ausführen.
Auch/gerade wenn gepeered wird/wurde (PEEREN: direkte "Verbindung" von Sensor/Fernbedienung etc. und Aktor   /   PAIREN: "Verbindung" zu einer Zentrale).


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

xray

Guten Abend zusammen,

ich bin eben wie folgt vorgegangen:
Drücken der Config-Taste am Sensor => ActionDetector wurde angelegt => die Readings können gelesen werden => set getconfig => die Readings waren wieder gefüllt => save config gedrückt.

Readings:
Internals:
   DEF        4E55BF
   IODev      RM_HmUART_EG
   LASTInputDev RM_HmUART_EG
   MSGCNT     35
   NAME       HM_4E55BF
   NOTIFYDEV  global
   NR         513
   NTFY_ORDER 50-HM_4E55BF
   RM_HmUART_EG_MSGCNT 35
   RM_HmUART_EG_RAWMSG 0501003E48A6104E55BF81xxxx0601C80E
   RM_HmUART_EG_RSSI -62
   RM_HmUART_EG_TIME 2016-12-14 19:38:12
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:48 - t:10 s:4E55BF d:81xxxx 0601C80E
   protLastRcv 2016-12-14 19:38:11
   protSnd    34 last_at:2016-12-14 19:38:12
   protState  CMDs_done
   rssi_at_RM_HmUART_EG avg:-64.51 cnt:35 min:-79 max:-60 lst:-62
   Readings:
     2016-12-14 17:59:00   Activity        alive
     2016-12-14 17:59:00   D-firmware      1.0
     2016-12-14 17:59:00   D-serialNr      NEQ0941501
     2016-12-14 17:58:21   PairedTo        0x81xxxx
     2016-12-14 17:58:21   R-cyclicInfoMsg on
     2016-12-14 17:58:22   R-eventDlyTime  0 s
     2016-12-14 17:58:21   R-pairCentral   0x81xxxx
     2016-12-14 17:58:21   R-sabotageMsg   on
     2016-12-14 17:58:22   R-sign          on
     2016-12-14 17:58:21   RegL_00.          02:01 09:01 0A:81 0B:B3 0C:77 10:01 14:06 00:00
     2016-12-14 17:58:22   RegL_01.          08:01 20:9C 21:00 30:06 00:00
     2016-12-14 19:38:12   alive           yes
     2016-12-14 19:38:12   battery         ok
     2016-12-14 19:38:12   contact         open (to RM_HmUART_EG)
     2016-12-14 19:38:12   recentStateType info
     2016-12-14 19:38:12   sabotageError   on
     2016-12-14 19:38:12   state           open
     2016-12-14 18:04:37   trigDst_81xxxx  noConfig
     2016-12-14 18:04:37   trigger_cnt     135
   Helper:
     HM_CMDNR   72
     cSnd       0181xxxx4E55BF01040000000001,0181xxxx4E55BF0103
     mId        00C7
     peerIDsRaw ,00000000
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4E55BF,00,00,00
       nextSend   1481740692.29061
       prefIO
       rxt        0
       vccu
       p:
         4E55BF
         00
         00
         00
     Mrssi:
       mNo        48
       Io:
         RM_HmUART_EG -60
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         RM_HmUART_EG
       flg        A
       ts         1481740692.00198
       ack:
         HASH(0x3a007b8)
         48800281xxxx4E55BF00
     Rssi:
       At_rm_hmuart_eg:
         avg        -64.5142857142857
         cnt        35
         lst        -62
         max        -60
         min        -79
     Shadowreg:
Attributes:
   IODev      RM_HmUART_EG
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       CUL_HM
   serialNr   NEQ0941501
   subType    threeStateSensor


"R-pairCentral   0x81xxxx " ist OK, korrekt?

Ergänzung in fhem.cfg:
define HM_4E55BF CUL_HM 4E55BF
attr HM_4E55BF IODev RM_HmUART_EG
attr HM_4E55BF actCycle 002:50
attr HM_4E55BF actStatus alive
attr HM_4E55BF autoReadReg 4_reqStatus
attr HM_4E55BF expert 2_raw
attr HM_4E55BF firmware 1.0
attr HM_4E55BF model HM-SEC-SCo
attr HM_4E55BF peerIDs 00000000,
attr HM_4E55BF room CUL_HM
attr HM_4E55BF serialNr NEQ0941501
attr HM_4E55BF subType threeStateSensor

define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector



Offensichtlich musste ich das "save config" anklicken, damit es gespeichert wurde und das trotz autocreate...  :o

Nach Stop & Start von fhem funktioniert nun auch weiterhin alles...  :D

Besten Dank nochmals für die Hilfe!

Grüße

xray

Otto123

Hi,

alles sieht gut aus :)

Nur noch aus Interesse, poste doch mal ein list autocreate

Gruß Otto
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

xray

Hallo Otto,

freut mich zu hören, dass jetzt alles OK ist!
Dann kann ich ja das nächste HM Spielzeug ordern... ;-)

Nachfolgend die Ausgabe von list autocreate:
Internals:
   NAME       autocreate
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
Attributes:
   filelog    ./log/%NAME-%Y.log


Viele Grüße

xray

Otto123

Hi xray,

sorry, ich war beim falschen Modul, gib doch bitte noch ein list global

Gruß Otto
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

xray

Kein Problem, bitte sehr:

Internals:
   DEF        no definition
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2016-12.log
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   latitude   50.684089
   logfile    ./log/fhem-%Y-%m.log
   longitude  7.069091
   modpath    .
   motd       SecurityCheck:

WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth.
telnetPort has no associated allowed device with password/globalpassword.

Restart FHEM for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

   statefile  ./log/fhem.save
   updateInBackground 1
   userattr   DbLogExclude DbLogInclude cmdIcon devStateIcon devStateStyle icon sortby stateFormat webCmd widgetOverride
   verbose    3
   version    fhem.pl:12680/2016-11-28


In der fhem.cfg steht folgendes:

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log


Grüße

xray

Otto123

Naja abschließend ist mir nicht klar warum autosave bei Dir nicht gesichert hat. Man könnte es in autocreate (alt) und in global deaktivieren. Hast Du aber nicht...
Aber ich muss ja nicht alles verstehen  :-[

Gruß Otto

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