HmIP-SWDM Device in FHEM anlegen - Reading Problem

Begonnen von deebeo, 20 Mai 2019, 12:02:17

Vorheriges Thema - Nächstes Thema

deebeo

Hallo Zusammen,

aus diversen Thermostat/Fensterkontakt-Sets habe ich zu Hause einige Fensterkontakte HmIP-SWDM in Betrieb. Diese wollte ich jetzt in FHEM einbinden.

Der RPC Server läuft und die Anbindung der CCU scheint mir soweit funtioniert zu haben. Beim get devicelist create (...) werden mir die Kontakte angelegt, allerdings scheint die Conf aus der hmccu_defattr.txt nicht zu passen, da das Gerät in FHEM mir als Reading "State" immer nur "initialized" zurück gibt.

Die HmIP_SWDM(ccutype "HmIP-SWDM" wird in FHEM angezeigt) kamen in meiner irgendwo heruntergeladenen hmccu_defattr.txt auch nicht vor, weshalb ich den Gerätenamen einfach mal hinten an die Conf für einen anderen Fensterkontakt gehängt habe(in der Hoffnung, dass die Teile gleich funktionieren).
An folgende 2 Blöcke habe ich in der ersten Zeile hinten "|HmIP-SWDM" angehängt:

channel:HM-Sec-SCo|HM-Sec-SC|HM-Sec-SC-2|HMIP-SWDO|HMIP_SWDM
_channels=1
_description=Tuer/Fensterkontakt optisch und magnetisch
ccureadingfilter=STATE
hmstatevals=ERROR!7:sabotage;SABOTAGE!1:sabotage
statedatapoint=STATE
substitute=STATE!(0|false):closed,(1|true):open

und

device:HM-Sec-SCo|HM-Sec-SC|HM-Sec-SC-2|HMIP-SWDO|HMIP_SWDM
_description=Tuer/Fensterkontakt optisch und magnetisch
ccureadingfilter=STATE
hmstatevals=ERROR!7:sabotage;SABOTAGE!1:sabotage
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open

get Deviceinfo bei Fenster geschlossen:
CHN 001558A99EFEBE:0 HM_FK_Bad:0
  DPT {b} HmIP-RF.001558A99EFEBE:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.INSTALL_TEST = true [RW]
  DPT {b} HmIP-RF.001558A99EFEBE:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE = 2.800000 [RE]
  DPT {i} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_DEVICE = 182 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_PEER = 0 [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UNREACH = true [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UPDATE_PENDING = false [RE]
CHN 001558A99EFEBE:1 HmIP-SWDM 001558A99EFEBE:1
  DPT {i} HmIP-RF.001558A99EFEBE:1.STATE = 0 [RE]

hier Fenster offen:

CHN 001558A99EFEBE:0 HM_FK_Bad:0
  DPT {b} HmIP-RF.001558A99EFEBE:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.INSTALL_TEST = true [RW]
  DPT {b} HmIP-RF.001558A99EFEBE:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE = 2.900000 [RE]
  DPT {i} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_DEVICE = 180 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_PEER = 0 [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UPDATE_PENDING = false [RE]
CHN 001558A99EFEBE:1 HmIP-SWDM 001558A99EFEBE:1
  DPT {i} HmIP-RF.001558A99EFEBE:1.STATE = 1 [RE]


So halb funktioniert das ganze also scheinbar schon. Irgendwie bekomme ich nur den Channel 1 State nicht als Reading in FHEM angezeigt.

Im Device des Fensterkontaktes in Fhem bleibt das Reading "State" nämlich immer unverändert auf "Initialized". Leider ist bei mir noch nicht der Groschen gefallen, wo ich was umbiegen muss damit der richtige Datenpunkt auf das Reading State gezogen wird. Ich bin sicher, dass die Lösung mega trivial ist. Hättet Ihr evtl einen Tipp oder auch Link für mich ?

Vielen Dank,
Daniel

zap

Was passiert, wenn Du für das Device "get update" ausführst?
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

deebeo

Zitat von: zap am 20 Mai 2019, 18:54:32
Was passiert, wenn Du für das Device "get update" ausführst?

Hi, danke für die Antwort.

Es gibt ein Reading "hmstate", welches nach get update aktualisiert wird(timestamp aktuell und rot). Das steht allerdings auch immer auf "initialized", egal ob Fenster offen oder geschlossen.

zap

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

deebeo

#4
Zitat von: zap am 22 Mai 2019, 07:18:30
Mach mal bitte ein list vom Device.

Das ist die Deviceinfo: - oder was meintest Du mit List?


CHN 001558A99EFEBE:0 HM_FK_Bad:0
  DPT {b} HmIP-RF.001558A99EFEBE:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.INSTALL_TEST = true [RW]
  DPT {b} HmIP-RF.001558A99EFEBE:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE = 2.800000 [RE]
  DPT {i} HmIP-RF.001558A99EFEBE:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_DEVICE = 173 [RE]
  DPT {n} HmIP-RF.001558A99EFEBE:0.RSSI_PEER = 0 [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.001558A99EFEBE:0.UPDATE_PENDING = false [RE]
CHN 001558A99EFEBE:1 HmIP-SWDM 001558A99EFEBE:1
  DPT {i} HmIP-RF.001558A99EFEBE:1.STATE = 0 [RE]

Falls Du get hm_FK_bad3(habe das dev mittlerweile 3 mal mit verschiedenen hmccu_defattr.txt angelegt, alles gleich) configlist meinst, da bekomme ich ohne weitere Argumente HMCCUDEV: HM_FK_Bad3 Cannot detect or create external RPC device

Danke für die Geduld!

zap

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

deebeo

Zitat von: zap am 10 Juli 2019, 17:59:42
Naja, der list Befehl von FHEM eben.



Ah, sorry :/ Hier:

Internals:
   CFGFN     
   DEF        001558A99EFEBE defaults
   FUUID      5d25eb8a-f33f-5181-597d-f24732b35ec1cf88
   IODev      d_ccu
   NAME       HM_FK_Bad3
   NR         112
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    001558A99EFEBE
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HM_FK_Bad
   ccutype    HmIP-SWDM
   channels   3
   statevals  devstate
   READINGS:
     2019-07-10 15:46:20   0.LOW_BAT       false
     2019-07-10 15:46:20   activity        false
     2019-07-10 15:46:20   hmstate         Initialized
     2019-07-10 15:43:38   state           Initialized
   hmccu:
     devspec    001558A99EFEBE
     dp:
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.DUTY_CYCLE:
         OVAL       false
         VAL        false
       0.INSTALL_TEST:
         OVAL       true
         VAL        true
       0.LOW_BAT:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.OPERATING_VOLTAGE:
         OVAL       2.800000
         VAL        2.800000
       0.OPERATING_VOLTAGE_STATUS:
         OVAL       0
         VAL        0
       0.RSSI_DEVICE:
         OVAL       173
         VAL        173
       0.RSSI_PEER:
         OVAL       0
         VAL        0
       0.UNREACH:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.UPDATE_PENDING:
         OVAL       false
         VAL        false
       1.STATE:
         OVAL       0
         VAL        0
Attributes:
   IODev      d_ccu

zap

Du hast kein einziges Attribut gesetzt?
Setze mal ccureadingfilter auf STATE
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

deebeo

#8
Zitat von: zap am 11 Juli 2019, 20:57:43
Du hast kein einziges Attribut gesetzt?
Setze mal ccureadingfilter auf STATE

Das war ein guter Tipp, jetzt wird mir neben dem device in der Liste auch der State angezeigt. Eine weitere Erkenntnis habe ich noch: Damit der State angezeigt wurde, musste ich von Device noch ein get devstate oder get update machen. Nach dem Öffnen oder Schließen des Fensters aktualisiert sich der State auch nicht automatisch in FHEM, sondern ebenfalls nur nach get devstate oder update. Muss ich der ccu oder dem rpcserver noch irgendwie sagen, dass er autoupdaten oder alle x Sekunden die Status aktualisieren soll? Außerdem scheint FHEM beim Anlegen des Devices auch die hmccu_defattr.txt komplett ignoriert zu haben, da hier bei jeden Absatz, in dem das HMIP_SWDM vorkommt, auch ein substitute=STATE!(0|false):closed,(1|true):open steht und der State tatsächlich nur als 0 oder 1 ankommt.

Das HMIP_SWDM habe ich in der Datei an 2 Stellen(1x Device, 1x Channel) von Hand hintendran geschrieben, da es im Originalfile nicht vorkam. Der Besitzer der Datei ist fhem.

device:HM-Sec-SCo|HM-Sec-SC|HM-Sec-SC-2|HMIP-SWDO|HMIP_SWDM
_description=Tuer/Fensterkontakt optisch und magnetisch
ccureadingfilter=STATE
hmstatevals=ERROR!7:sabotage;SABOTAGE!1:sabotage
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open


Langsam sehe ich licht am Ende des Tunnels :) Danke!

EDIT: Google ist mein Freund. Habe ich vielleicht Set Defaults vergessen?
Set defaults im Device fördert ein
HMCCUDEV: HM_FK_BAD HMCCU: No default attributes found
zu Tage.
Erneutes set d_ccu importdefaults /opt/fhem/hmccu_defattr.txt und set defaults bringen das gleiche Ergebnis.

deebeo

Google ist schon wieder mein Freund. Ursache für das fehlende Aktualisieren war der rpcserver: Protokoll HMIP-RF samt Port hat gefehlt. Geht jetzt.

Offen bleibt die Frage, warum die Standards aus der hmccu_defattr.txt nicht greifen. hast Du da evtl einen Ansatzpunkt?