HMCCU 5.0 Beta verfügbar

Begonnen von zap, 05 Januar 2020, 19:49:52

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 20 21 22 23 24 ... 59
Benutzer-Aktionen

Ralph

#315
20 Januar 2021, 16:25:15
Moin,
Beobachtung, Hinweis und eine Bitte.

Derzeit betreibe ich noch RasPi mit HmUART, der ja nur BidCos kann, das aber ganz gut.
Umstellen will ich auf debmatic CCU mit USB-Stick nach Alex R.

Bisher sieht ein HM_Sec_SD_2 so aus:
Code Auswählen

Internals:
...
   IODev      HmUART
   LASTInputDev HmUART
   NAME       RM_Flur
...
   TYPE       CUL_HM
...
   READINGS:
     2021-01-19 19:35:34   Activity        alive
     2019-05-02 15:20:18   CommandAccepted yes
     2019-05-02 15:20:10   D-firmware      1.0
...
     2021-01-20 14:50:28   alarmTest       ok
     2021-01-20 14:50:28   battery         ok
     2021-01-20 14:50:28   commState       CMDs_done
     2021-01-20 14:50:28   level           0
     2021-01-18 15:28:48   powerOn         2021-01-18 15:28:48
     2021-01-20 14:50:28   recentStateType info
     2019-05-28 11:26:00   sdRepeat        off
     2021-01-20 14:50:28   smokeChamber    ok
     2021-01-20 14:50:28   state           off
     2021-01-18 15:54:08   trigger_cnt     4


Unter Beta 4.4 sieht das bei mir so aus:
Code Auswählen

Internals:
...
   IODev      d_ccu
   NAME       HM_Sec_SD_2_....
   NR         118
   STATE      ???
   TYPE       HMCCUCHN
   ccuaddr    ....:1
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    HM-Sec-SD-2 ....:1
   ccurolestate SMOKE_DETECTOR
   ccusubtype HM-Sec-SD-2
   ccutype    HM-Sec-SD-2
   readonly   no
   READINGS:
     2021-01-20 15:28:23   ERROR_ALARM_TEST NO_ERROR
     2021-01-20 15:28:23   ERROR_SMOKE_CHAMBER NO_ERROR
     2021-01-20 15:28:23   LOWBAT          ok
     2021-01-20 15:28:23   STATE           false
     2021-01-20 15:28:23   activity        alive
     2021-01-20 15:28:23   battery         ok
     2021-01-20 15:28:23   devstate        ok
     2021-01-20 15:28:23   rssidevice      N/A
     2021-01-20 15:28:23   rssipeer        -43
     2021-01-20 15:28:23   sign            off
   hmccu:
...
Attributes:
   IODev      d_ccu
...


Was ich mir wünsche und darum bitte:

Dass die Readings von oben, nämlich
     2021-01-18 15:28:48   powerOn         2021-01-18 15:28:48
     2021-01-20 14:50:28   state           off
     2021-01-18 15:54:08   trigger_cnt     4
auch in den Readings via HMCCUCHN so erscheinen.

Grund:
in trigger_cnt steckt wann der letzte echte Alarm war / ist und zum wievielten Mal Alarm war
und
an powerOn kann man erkennen, ob wer das Teil mal abgehängt hat(te).
Das hatte ich schon. Melder abgehängt, rumgeflext, Melder wieder angehängt = neues datum.
Beides wird - mindestens bei mir - überwacht.

Ich täte es ja - wenn möglich - selber tun. Wennich denn nur begreifen würde, WIE ?

Bitte sagts mir oder tut es bitte für mich.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

zap

#316
20 Januar 2021, 17:29:59
@Ralph

Könnte sein, dass HMCCU den Smokedetector nicht richtig zuordnet. Könnte ich bitte die Ausgabe von get deviceInfo und get paramDesc haben?
Ich kann Dir nicht versprechen, dass das alles automatisch gehen wird. Allerdings kann man einiges sicher mit geschickten Attribut-Definitionen hinbiegen.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

#317
20 Januar 2021, 17:32:42
Zitat von: fredje am 20 Januar 2021, 14:18:52
Hallo Zap, eine Frage die nicht direkt mit dem HMCCU Adapter zu tun hat. Es geht um rpc.

Momentan habe ich fhem so eingerichtat das ich über rpc auf meine CCU3 zugreife.
Nun möchte ich zusätzlich mit ioBroker auf die CCU3 mit rpc zugreifen. Ist dies möglich
oder gibt dies Probleme da beide auf die selben ports der ccu zugreifen.

Danke ...

Nein, dass funktioniert problemlos parallel. Bei mir läuft FHEM, ioBroker und openHab gleichzeitig. Alle 3 sind per RPC an die gleiche CCU angebunden. Eine CCU3 steckt das auch Performance mäßig locker weg.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

juemuc

#318
20 Januar 2021, 20:02:16
Hallo zap,

ich habe heute nach einem Neustart wieder diese Meldungen. Eventuell wird etwas zu früh gestartet?

Code Auswählen
2021.01.20 18:31:25 2: HMCCU [HMCCU3] Get RPC device for interface HmIP-RF
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server process started for interface BidCos-RF with PID=7115
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Initializing RPC server CB2001070060070063 for interface BidCos-RF
2021.01.20 18:31:25 1: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server starting
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Callback server CB2001070060070063 created. Listening on port 7411
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] CB2001070060070063 accepting connections. PID=7115
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1324.
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1325.
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1321.
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] RPC server process started for interface HmIP-RF with PID=7116
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] Initializing RPC server CB2010070060070063 for interface HmIP-RF
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063HmIP_RF] RPC server starting
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] Callback server CB2010070060070063 created. Listening on port 7420
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] CB2010070060070063 accepting connections. PID=7116
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server CB2001070060070063 enters server loop
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Registering callback http://192.168.70.60:7411/fh2001 of type A with ID CB2001070060070063 at http://192.168.70.63:2001
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server CB2001070060070063 running
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063BidCos_RF] Scheduled CCU ping every 300 seconds

Es funktioniert aber noch alles  ;D

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Ralph

#319
20 Januar 2021, 20:50:35 Letzte Bearbeitung: 20 Januar 2021, 20:53:42 von Ralph
Zitat von: zap am 20 Januar 2021, 17:29:59
Post #316
... Ausgabe von get deviceInfo und get paramDesc ...


Code Auswählen
Device channels and datapoints
CHN NEQ0441853:0 HM-Sec-SD-2 NEQ0441853:0
  DPT {b} BidCos-RF.NEQ0441853:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.NEQ0441853:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.NEQ0441853:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.NEQ0441853:0.LOWBAT = false [RE]
  DPT {b} BidCos-RF.NEQ0441853:0.DUTYCYCLE = false [RE]
  DPT {n} BidCos-RF.NEQ0441853:0.RSSI_DEVICE = 1 [RE]
  DPT {n} BidCos-RF.NEQ0441853:0.RSSI_PEER = 1 [RE]
  DPT {n} BidCos-RF.NEQ0441853:0.AES_KEY = 0 [R]
CHN NEQ0441853:1 HM-Sec-SD-2 NEQ0441853:1
  DPT {i} BidCos-RF.NEQ0441853:1.ERROR_ALARM_TEST = 0 [RE]
  DPT {i} BidCos-RF.NEQ0441853:1.ERROR_SMOKE_CHAMBER = 0 [RE]
  DPT {b} BidCos-RF.NEQ0441853:1.STATE = false [RE]
  DPT {b} BidCos-RF.NEQ0441853:1.LOWBAT = false [RE]
  DPT {b} BidCos-RF.NEQ0441853:1.INSTALL_TEST =  [E]

Device detection:
StateDatapoint = 1.SMOKE_DETECTOR_ALARM_STATUS SMOKE_DETECTOR
No control datapoint detected

Recommended module for device definition: HMCCUCHN
Device description
Device NEQ0441853 HM-Sec-SD-2 NEQ0441853 [HM-Sec-SD-2]
  CHILDREN: NEQ0441853:0,NEQ0441853:1
  FIRMWARE: 1.0
  FLAGS: Visible
  INTERFACE: KEQ0583730
  PARAMSETS: MASTER
  RF_ADDRESS: 4959260
  ROAMING: 0
  RX_MODE: BURST
  UPDATABLE: 0
Channel NEQ0441853:0 HM-Sec-SD-2 NEQ0441853:0 [MAINTENANCE]
  AES_ACTIVE: 0
  DIRECTION: NONE
  FLAGS: Visible,Internal
  PARAMSETS: MASTER,VALUES
  PARENT: NEQ0441853
  PARENT_TYPE: HM-Sec-SD-2
Channel NEQ0441853:1 HM-Sec-SD-2 NEQ0441853:1 [SMOKE_DETECTOR] known
  AES_ACTIVE: 1
  DIRECTION: SENDER
  FLAGS: Visible
  PARAMSETS: MASTER,VALUES
  PARENT: NEQ0441853
  PARENT_TYPE: HM-Sec-SD-2
  TEAM: *NEQ0441853:1
  TEAM_TAG: smoke_detector



Code Auswählen
Device
  Paramset MASTER
    DEV_RPT_CNT_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Channel 0
  Paramset VALUES
    AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
    CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    DUTYCYCLE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
    RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
    STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
    UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
  Paramset VALUES
    ERROR_ALARM_TEST: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0 VALUES=NO_ERROR,ALARM_TEST_FAILED
    ERROR_SMOKE_CHAMBER: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0 VALUES=NO_ERROR,DEGRADED_SMOKE_CHAMBER
    INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
    LOWBAT: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
    STATE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

zap

#320
21 Januar 2021, 07:57:54
@juemuc: Diese Meldungen werden beim Auslesen der CCU Programme verursacht. Entweder ist das ein Fehler in HMCCU oder eines der CCU Programme ist in einem undefinierten Zustand. Ich habe das Logging an der Stelle erweitert. Ich checke heute oder morgen die neue Version ein.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

#321
21 Januar 2021, 09:27:33
@Ralph Danke für die Infos. Kern des Problems ist, dass HMCCU Deinen Rauchmelder (BidCos) für einen HmIP Rauchmelder hält. Normalerweise hat EQ-3 das von Herstellerseite getrennt, d.h. die internen Bezeichnungen unterscheidet sich.

Beispiel Taster: der BidCos Taster hat die Rolle "KEY" während der HmIP Taster die Rolle "KEY_TRANSCEIVER" hat. Dadurch kann HMCCU bei unterscheiden.

Bei den Rauchmeldern hingegen läuft alles (BidCos und HmIP) unter "SMOKE_DETECTOR".

Folge: HMCCU verwendet den HmIP-Datenpunkt SMOKE_DETECTOR_ALARM_STATUS für Deinen Rauchmelder, obwohl der bei Dir STATE heißt.

Folge für mich: Ich muss diesen Lapsus auf EQ-3 Seite bei mir irgendwie ausbügeln.

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

Ralph

#322
21 Januar 2021, 17:12:07
Zitat von: zap am 21 Januar 2021, 09:27:33
Folge für mich: Ich muss diesen Lapsus auf EQ-3 Seite bei mir irgendwie ausbügeln.
Mist. Danke für Mühe. Wäre nett, falls Du dazu kommst.

Ich grüble gerade darüber nach, ob es nicht möglich wäre, den HM-UART-Aufsteck-Chip und (m)einen USB-Stick mit HMCCU parallel laufen zu lassen und mit dem Stick und debmatic dann nur HM-IP zu bedienen und die alten HM-Teile nach wie vor über den HM-UART-Aufsteck-Chip abzuhandeln. Dann könnte man sich die Verbiegerei sparen. Nur so ein Gedanke.


Im Moment habe ich leider ein neues Problem.

Nach kompletter Neuinstallation eines Raspberry 3 B+ mit
HMCCU nach: https://forum.fhem.de/index.php/topic,107077.0.html
und
define myCCU HMCCU IP-Addresse
kommt nun plötzlich im Log

2021.01.21 16:51:03 1: reload: Error:Modul 88_HMCCU deactivated:
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 37.
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module)  (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/88_HMCCU.pm line 37.

Gelesen und verstanden habe ich das wohl, nur
wie ich das (nach) installiere, das weiß ich leider nicht.

Kochrezept erbeten.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

kjmEjfu

#323
21 Januar 2021, 17:24:15
Migriere derzeit zu Home Assistant

Ralph

#324
21 Januar 2021, 17:47:57
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

Ralph

#325
21 Januar 2021, 20:44:07 Letzte Bearbeitung: 21 Januar 2021, 20:45:57 von Ralph
Zitat von: zap am 21 Januar 2021, 09:27:33

zu #315 , #316 , #319 , #321


Diese DOIF meldet den FeuerAlarm.
Code Auswählen

defmod di_HM_RM_WoZi DOIF ([HM_RM_WoZi:"^STATE:.true$"]) ({DebianMail('deinemail@spam.it','^ Alarm $DEVICE FEUER',ReadingsTimestamp("$DEVICE","STATE","0"))})

Zum Testen setze in der DOIF den STATE auf false. Und drücke den Taster am Melder.

Das löst das Problem des Counters und des Power On in den oberen Posts leider noch nicht
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

zap

#326
22 Januar 2021, 10:58:17
@Ralph

Da hat CUL_HM wohl einige Sonderlocken eingebaut.

state wird gehen, sobald ich die Device Config aktualisiert habe. Die anderen beiden Readings musst Du Dir mit FHEM Bordmitteln (z.B. Dummy Device oder User Readings ) selbst bauen.

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

Ralph

#327
22 Januar 2021, 13:58:11
Zitat von: zap am 22 Januar 2021, 10:58:17
Da hat CUL_HM wohl einige Sonderlocken eingebaut.
Ja, SCHÖNE !

Den "state" hab ich mir mal selbst gebaut:
Code Auswählen
attr HM_RM_WoZi userReadings state {ReadingsVal("HM_RM_WoZi","devstate",0)}
Den braucht man nämlich so und dringend, wenn man eine sub verwendet, die prüft, ob sich die Devices regelmäßig melden.
Dieses Relikt aus FS20-Zeiten verwende ich noch, weil: a) ich solche noch betreibe und b) modernere eingebunden werden.

Wie das mit den anderen gehen soll, das ist mir völlig unklar ?
Bleibt mir wohl nur der Ansatz mit dem Mischbetrieb, debmatic macht dann eben nur Hm-IP, CUL_HM macht HM-alt.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

zap

#328
22 Januar 2021, 15:37:21
Hier geht es z.B. um einen Zähler, der mit DOIF realisiert wurde:

https://forum.fhem.de/index.php?topic=100614.0

Also ich denke, beide Anforderungen lassen sich mit Bordmitteln lösen. Aber Du kannst natürlich auch zweigleisig fahren.

P.S. Ein Counter zum Zählen der Rauchmelder-Alarme wäre bei mir seit 2 Jahren = 0. Wozu brauchst Du diese Info?
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Ralph

#329
22 Januar 2021, 18:52:29
@zap
Danke für den Zähler, wieder was dazugelernt.

@all z. K.
Die Rauchmelder HM_Sec_SD_2 sind unter CUL_HM hervorragend und unter HMCCU so besch... bedient,
dass ich diese aus debmatic mit HMCCU ausgliedere und wieder zurück in CUL_HM eingliedere.
( @ zap: wegen mir brauchst Du Dich deswegen nicht weiter zu bemühen und die Schwächen von eQ-3 verbessern )
Letzlich ausschlaggebender Punkt ist, dass die regelmäßige "alive"-Meldung nicht in der von mir gewünschten Form kommt.
Ich muss also doppelgleisig fahren.
Höchst bedauerlich.

Wer vergleichn möchte: oben sind Auszüge.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen
Drucken
Nach oben Seiten 1 ... 20 21 22 23 24 ... 59
Benutzer-Aktionen