Fragen zu HMCCU mit Rauchmeldern HM-Sec-SD-2

[connormcl]

Hallo,

bin Anfänger im Bereich Homematic/HMCCU.

Habe mittels HMCCU die CCU2 an FHEM angebunden und meine in der CCU2 angelernten HM-Sec-SD-2 konnte ich wie im Wiki beschrieben in FHEM autocreaten lassen über:
get d_ccu devicelist create RM t=dev f=HM_%n room=Homematic

Danach habe ich mittels
- get defaults
- set defaults
- get deviceinfo
- get devstate

das Ganze soweit hinbekommen, dass ich die Werte der Rauchmelder sehen kann und ein State gesetzt wurde; siehe Screenshot im Anhang.


Nun habe ich zwei Fragen:

- Wie kann ich den STATE in FHEM umschreiben oder/und die Readings erweitern so dass mir der auch  der Batteriestatus der Rauchmelder angezeigt wird?

- Die Readings der Rauchmelder updaten sich anscheinend nur, wenn ich "get devstate" durchführe. Muss ich das immer manuell tun oder wann sendet die ccu2 hier ein update? Kommt da einmal am Tag etwas zum Zustand der Rauchmelder oder nur wenn sich eine Änderung ergibt? bzw. kommt da etwas im Alarmfall an?

[zap]

sTATE kannst Du mit dem FHEM Standard Attribut stateformat beeinflussen.
Du solltest eigentlich auch ein Reading battery haben. Führe bitte mal den Befehl get Update aus.
Damit die Readings automatisch aktualisiert werden, musst du den RPC Server starten. Wie das geht, steht im Wiki.

[connormcl]

get update funktioniert und gibt mir einen aktuellen Status
Es scheint das gleiche zu tun wie get devstate?

Meine beiden Test-Rauchmelder bzw. die CCU2 haben heute morgen um 8 und 10 Uhr jeweils ein Statusupdate zu FHEM durchgeschickt. Habe das Logging auf der CCU2 mal eingeschaltet um zu sehen, ob der Status nun von den Rauchmeldern oder von der CCU2 kommt. Scheint aber generell zu funktionieren.

Nun wäre es noch toll, wenn ich hinter dem "ok" des Rauchmelder-Status noch den Batteriestatus anzeigen könnte, wie bei den Thermometern.

Also: STATE ok Bat: ok
oder soetwas.

Den Batteriestatus finde ich in FHEM allerdings nicht in den Readings...siehe Screenshot im ersten Post.

Wenn ich get RM deviceinfo ausführe, kann ich den Batteriestatus aber sehen:

CHN NBO0010770:0 RM_Hobbyraum:0
  DPT {b} BidCos-RF.NBO0010770:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.NBO0010770:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.NBO0010770:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.NBO0010770:0.LOWBAT = false [RE]
  DPT {b} BidCos-RF.NBO0010770:0.DUTYCYCLE = false [RE]
  DPT {n} BidCos-RF.NBO0010770:0.RSSI_DEVICE = 1 [RE]
  DPT {n} BidCos-RF.NBO0010770:0.RSSI_PEER = 210 [RE]
  DPT {n} BidCos-RF.NBO0010770:0.AES_KEY = 0 [R]
CHN NBO0010770:1 HM-Sec-SD-2 NBO0010770:1
  DPT {i} BidCos-RF.NBO0010770:1.ERROR_ALARM_TEST = 0 [RE]
  DPT {i} BidCos-RF.NBO0010770:1.ERROR_SMOKE_CHAMBER = 0 [RE]
  DPT {b} BidCos-RF.NBO0010770:1.STATE = false [RE]
  DPT {b} BidCos-RF.NBO0010770:1.LOWBAT = false [RE]
  DPT {b} BidCos-RF.NBO0010770:1.INSTALL_TEST =  [E]

Ich muss also wohl selbst ein Reading definieren, das einen Datenpunkt ausliest? Und danach den State selbst aus den Readingwerten aufbauen?

Ist das richtig? Gibt es hierzu evtl. irgendwo eine verständliche Anleitung?

[zap]

Wie sehen bei Dir im Device d_ccu die Attribute ccudef-readingfilter und ccudef-readingname aus?
Sind die gesetzt und wenn ja auf welchen Wert?

[connormcl]

Bei meinen Rauchmeldern ist noch alles so, wie durch get defaults angelegt:

IODev d_ccu
ccureadingfilter STATE
hmstatevals ERROR_ALARM_TEST!1:alarm_test_failed;ERROR_SMOKE_CHAMBER!1:degraded_smoke_chamber
statedatapoint 1.STATE
substitute STATE!(0|false):ok,(1|true):alarm;ERROR_ALARM_TEST!0:no,1:failed;ERROR_SMOKE_CHAMBER!0:no,1:degraded

Damit hat er drei Readings erzeugt:

1.STATE ok 2017-04-28 17:22:11
hmstate ok 2017-04-28 17:22:11
state ok 2017-04-28 17:22:11


EDIT: habe gerade gesehen, dass meine HMCCUConf.pm die Version 3.9 ist....evtl. liegt es daran und ich muss updaten?

[zap]

Update kann kein Fehler sein. Ich hatte allerdings nach den beiden Attributen im IO Device gefragt ...
Die könnten das Anlegen des battery Readings verhindern

[connormcl]

Ja sorry, habe ich verwechselt.

Beim d_ccu sind die beiden Attribute gar nicht gesetzt.

Dort sind nur folgende definiert:

rpcinterfaces BidCos-RF
rpcinterval 5
rpcport 2001
rpcqueue /tmp/ccuqueue
stateFormat rpcstate/state

[zap]

Wenn Du für den Rauchmelder den Befehl get update ausführst, wird dann ein Reading battery angelegt?

Prüfe auch bitte mal die Ausgabe von folgendem Befehl:

get d_ccu rpcstate

[connormcl]

get update:
Ich bekomme eine Aktualisierung der angelegten readings:

1.STATE ok 2017-05-03 20:09:03
hmstate ok 2017-05-03 20:09:03
state ok 2017-05-03 20:09:03

nix mit Batterie...

(wenn ich wie früher schon geschrieben get deviceinfo mache, bekomme ich die Batterie....(aber nicht als Reading, wo ich sie gerne hätte...)

  DPT {b} BidCos-RF.NBO0024641:1.LOWBAT = false [RE]


Der rpc-Server läuft, sonst würden ja keine Daten von den Rauchmeldern reinkommen.

get d_ccu rpcstate scheitert aber an inkompatiblem ps:
ps: unrecognized option: a
BusyBox v1.25.1 () multi-call binary.

Usage: ps

Show list of processes

   w   Wide output

[connormcl]

Nach Update von HMCCUConf.pm und HMConfig.pm scheine ich nun weitere Readings zu bekommen.

Muss mal sehen, wie sich die entwickeln und ob ich die überall nachrüsten kann:

0.AES_KEY 0 2017-05-03 20:23:35
0.CONFIG_PENDING false 2017-05-03 20:23:35
0.DUTYCYCLE false 2017-05-03 20:23:35
0.LOWBAT false 2017-05-03 20:23:35
0.RSSI_DEVICE 1 2017-05-03 20:23:35
0.RSSI_PEER 69 2017-05-03 20:23:35
0.STICKY_UNREACH false 2017-05-03 20:23:35
0.UNREACH false 2017-05-03 20:23:35
1.ERROR_ALARM_TEST 0 2017-05-03 20:23:35
1.ERROR_SMOKE_CHAMBER 0 2017-05-03 20:23:35
1.LOWBAT false 2017-05-03 20:23:35
1.STATE ok 2017-05-03 20:25:25
hmstate ok 2017-05-03 20:25:25
state ok 2017-05-03 20:25:25


EDIT:

nein, bei den anderen Rauchmeldern bekomme ich diese Readings nicht zu sehen, egal was ich mache...auch wenn ich sie in FHEM lösche und neu importiere...

Liegt das an der CCU2?

EDIT2:

Habe nochmal einen Rauchmelder ohne die Readings komplett aus der CCU2 und FHEM entfernt; danach wieder angelernt und von FHEM suchen lassen...es erscheinen weiterhin hier keine Readings ausser 1.STATE, hmstate, state.


EDIT3:

Nun bin ich ein kleines bischen weiter...ich kann die Readings manuell erzeugen, indem ich folgendes mache:

get [Rauchmelder] datapoint 1.LOWBAT

danach bekomme ich sofort ein Reading angelegt:
1.LOWBAT false 2017-05-03 21:11:24

Sollte das nicht irgendwie automatisch laufen? Wie gesagt, ich weiss noch nicht wie das Zusammenspiel zwischen FHEM und CCU2 aussehen sollte, wenn es normal läuft...

[zap]

Auf welcher Plattform läuft Dein FHEM eigentlich, wenn das ps nicht funktioniert?

Wie auch immer: welche Readings dargestellt werden, hängt vom Attribut ccureadingfilter ab. Wenn Du alle Readings haben möchtest, setze das Attribut bei allen Rauchmeldern auf .*

Testen kannst Du das mit "get update".

Da man aber in den seltensten Fällen alle Readings braucht, schränkt man das in ccureadingfilter eben ein, z.B. mit dem Ausdruck (LOWBAT|STATE)

[connormcl]

Ist (LOWBAT|STATE) die Standardeinstellung für den ccureadingfilter? Wer hätte die setzen müssen? Ich? -werde damit mal probieren, Danke!

Das Ganze Setup läuft auf LEDE/OpenWRT auf einem Raspberry Pi 3 B.

Hatte immer wieder gelesen, dass Leute auf ihren Routern OpenWRT betreiben bzw. dann FHEM dazuinstallieren.

Ist ein Super Router mit Filterfunktionen um Windows 10 in Schach zu halten, aber wohl nicht die beste (Software-)Plattform für FHEM.

Das Linux ist sehr eigen und stark limitiert, weil es auch auf kleinsten Routern laufen soll...und die Perl Module sind nicht vollständig vorhanden...bspw. fehlt Net:SSLeay und ich musste deswegen eine CCU2 für Homematic anschaffen und ein VPN installieren zur Absicherung von FHEMWEB.

[zap]

Es ist etwas komplizierter: wenn weder ccureadingfilter noch ccudef-readingfilter (im IO Device) gesetzt sind, werden alle Readings übertragen. Wenn beide Attributes gesetzt sind, werden die Filter kombiniert bzw Oder-verknüpft.

Wenn Du also keines der Attributes gesetzt hast, müssten alle Readings erscheinen, zumindest bei einem get Update. Wenn sie nicht automatisch aktualisiert werden, liegt es daran, dass der RPC Server nicht läuft.


Ach ja: HMConfig.pm gehört nicht zu HMCCU sondern zu CUL_HM.