Bis jetzt habe ich viele klassische Homematic-Sensoren und -Aktoren im Einsatz. Die Zukunft dürfte vermutlich aber HomematicIP gehören. Es macht vermutlich Sinn, neue Sensoren und Aktoren als HomematicIP-Geräte anzuschaffen.
Derzeit habe ich HmLanGws über das RaspberryPi-Aufsteckmodul HM-MOD-RPI-PCB im Einsatz. Soweit ich das verstanden habe, könnte ich das für HomematicIP auch verwenden (mit piVCCU). Ich kann also eines meiner LAN-Gateways abzweigen und es für piVCCU konfigurieren, richtig? Das dann gleich mit der CCU3 firmware (oder spricht was für die CCU2)? Dann hätte ich aber nur eine Instanz. So einfach wie mit den HmLanGws beim herkömmlichen Homematic wird's vermutlich nicht gehen...
Setzt ihr schon im großen Stil HomematicIP ein? Wenn ja, wie macht ihr das?
LG
Ronald
Zitat von: ronzo am 15 Oktober 2020, 12:40:30
Bis jetzt habe ich viele klassische Homematic-Sensoren und -Aktoren im Einsatz. Die Zukunft dürfte vermutlich aber HomematicIP gehören.
Die Zukunft bei eQ-3, ja.
Da aber HM-"Classic" und "HM-IP" sowieso getrennte Welten sind, die über eine CCUx (CCU2 ist dem Vernehmen nach einfach langsam und daher nicht mehr zu empfehlen) auch eigentlich nur indirekt miteinander kommunizieren, stellt sich die Frage, ob es denn ggf. auch andere Alternativen gibt, was den Anbieter angeht....
Von daher ist meine private Entscheidung eher die, künftig eher Z.* einzusetzen: Z-Wave tendenziell für "klassische Aktoren" (Rollläden und Jalousien, on/off-Geräte), ZigBee tendenziell für (dimmbare) Beleuchtung und Sensorik. Da kann ich wenigstens den Hersteller wechseln, wenn er mir auf den Zeiger geht oder kann zwischen mehreren Alternativen wählen...
(Einarbeiten muß man sich m.E. in alle neuen Welten, wenn man bisher CUL_HM genutzt hat).
Just my2ct.
Zitat von: Beta-User am 15 Oktober 2020, 12:58:09
Die Zukunft bei eQ-3, ja.
...
Von daher ist meine private Entscheidung eher die, künftig eher Z.* einzusetzen: Z-Wave tendenziell für "klassische Aktoren" (Rollläden und Jalousien, on/off-Geräte), ZigBee tendenziell für (dimmbare) Beleuchtung und Sensorik. Da kann ich wenigstens den Hersteller wechseln, wenn er mir auf den Zeiger geht oder kann zwischen mehreren Alternativen wählen...
Danke für deine Antwort! Mir persönlich ist HmIP irgendwie nicht sonderlich sympathisch. Da ich ohnehin schon einen DeConz bei mir im Einsatz habe, werde ich mich hier mal schlau machen. Gibt es empfehlungen zu ZigBee-Dimmaktoren und -Tastern?
Zitat von: ronzo am 15 Oktober 2020, 13:39:59
Danke für deine Antwort! Mir persönlich ist HmIP irgendwie nicht sonderlich sympathisch.
Ich habe mich irgendwann so über die Preispolitik von eQ-3 bei HM geärgert, dass es mir gar nicht mehr speziell auf HmIP ankam. Aber dass da nur einzelne Aktoren Mesh machen, finde ich irgendwie "beschränkt" (es kann gute Gründe geben, Vorgaben für Mesh-Funktionalität zu machen, aber das herstellerseitig vorzugeben finde ich sch... Genauso wie es unverständlich ist, wieso ein Rollladenaktor nicht als Jalousieaktor konfiguriert werden kann. Usw. usf.).
ZitatDa ich ohnehin schon einen DeConz bei mir im Einsatz habe, werde ich mich hier mal schlau machen. Gibt es empfehlungen zu ZigBee-Dimmaktoren und -Tastern?
Kommt darauf an, was du genau suchst:
- Dimmer
Unterputz gibt es - afaik - was von Dresden Elektronik selbst, und diverse Baumarkt- (Paulmann?)-Varianten und tint. Ich habe bisher nur diverse "klassische" Leuchtmittel für E27 usw.. Aber generell einfach in die Kompabilitätsliste schauen oder eben "auf Risiko" kaufen - die ZigBee-Profile sind ja generisch und meistens dauert es nicht lange, bis neue/bisher noch nicht bekannte Hardware integriert ist.
- Taster
Es gibt zum einen auch Dimmereinsätze von Gira (?, u.a.?) mit passenden "Aufsteckern", ansonsten ist es mit Tasterintegration relativ mau. Am ehesten noch die "opple". Zu dem 6-er gibt es einen Thread, da sind weitere Links zu den Abmessungen usw. drin. Die originalen von Jung (und wohl noch einer "klassischen" Schalterserien-Fa.) sind dagegen technisch überholt und jedenfalls in der vorliegenden Version nicht gut (aber hübsch).
(Da fällt mir grade ein, dass man uU. die "kleinen mit den runden Ecken" vom gelben Möbelhaus vielleicht recht einfach als Basis für Bastellösungen hernehmen könnte...? Die sind jedenfalls recht klein).
Ich stehe greda vor einer ähnlichen Entscheidung... Für eine zweites Haus wollte ich anfangen Komponenten zu kaufen und bin überall nur noch über HomematicIP statt Homematic gestolpert.
Auch mir ist HomematicIP nicht sonderlich symphatisch.
- Die Auswahl bei Homematic / HomematicIP an Geräten ist schon gut - würde ich ungern vermissen.
- Die Preise sollte eher niedriger als höher sein.
So wie ich es verstanden habe gibt es also noch keine gute Alternative?
Zitat von: bmaehr am 02 November 2020, 22:41:35
So wie ich es verstanden habe gibt es also noch keine gute Alternative?
Was ist eine "gute Alternative"?
Meiner persönlichen Meinung nach ist HM-IP keine gute Alternative, aber kurz zusammengefaßt ist es halt schlicht und ergreifend so: DAS perfekte System gibt es nicht...
Ein herzerfrischendes "Moin" vom achtern Diek.
Zitat von: Beta-User am 03 November 2020, 08:08:30
Was ist eine "gute Alternative"?
Eine gute Alternative ist aus meiner Sicht:
- eine robuste Hardware die nicht nach 12 bis 24 Monaten auseinander fällt bzw. den Geist aufgibt
- auf einem offenen Kommunikations-Standard (MQTT)
- einen Funkstandard ohne Begrenzung (1%-Regel bei 884MHz) beruht.
- halbwegs gut aussieht. (Wenn ich da an manche Rauchmelder denke fühlt man sich an Raumschiff Orion erinnert)
Aber ich fürchte, da kann mann lange suchen...
Zur Zeit habe ich ein homogenes Homematic System im Haus am Laufen.
Der Heizkörper-Stellaktor ist alles andere als ein mechanisch robustes Gerät.
Kurz dagegen kommen, fliegt der runde Stell-Deckel ab und der R6 wartet auch nur darauf, einen leichten mechanischen Stoß zu bekommen um das gesamte Gerät mit einem F12 ins Nirvana zu verabschieden.
https://forum.fhem.de/index.php?topic=64446.0
Die Unterputz - Aktoren halten sich nicht an die Norm und füllen die gesamte Standard - UP-Dose aus.
Das hat zur Folge, dass man keine zusätzlichen WAKO-Klemmen hinter den Aktor untergebracht bekommt.
Nebenbei: Die Preise steigen und steigen.
Irgendwann ist meine Schmerzgrenze erreicht und ich werde wechseln müssen.
Gruss
Sailor
PS: Tut gut mal seinen Frust los zu schreiben...
Würde HomematicIP mit einem Konzept wie den LAN-Gateways für Homematic funktionieren, hätte ich vermutlich schon einige IP-Komponenten. So finde ich das neue System aber einfach unattraktiv.
Zumindest habe ich durch Homematic löten gelernt. Etwas, was ich sonst vermutlich nie gemacht hätte... (nicht jeder SmartHome-interessierte Mensch ist Elektriker oder Elektrotechniker...)
Habe mittlerweile einige Steckdosen-Adapter und Beleuchtung mit Zigbee.
Zitat von: ronzo am 03 November 2020, 09:21:22
Würde HomematicIP mit einem Konzept wie den LAN-Gateways für Homematic funktionieren, hätte ich vermutlich schon einige IP-Komponenten. So finde ich das neue System aber einfach unattraktiv.
Was für ein Konzept meinst du? Die HmIP-HAP haben kürzlich ein Firmware-Update bekommen, mit dem man sie wie ein HMLANGW einsetzen kann. Ich hab mir gleich mal ein paar Silvercrest-gelabelte für etwa 15-20€ pro Stück besorgt, unschlagbar gegenüber den HMLANGW.
https://www.homematic-inside.de/blog/homematic-ip-access-point-hmip-hap-als-lan-router-auf-ccu3-installieren-und-anlernen
Zitat von: Sailor am 03 November 2020, 09:10:03
Eine gute Alternative ist aus meiner Sicht:
- eine robuste Hardware die nicht nach 12 bis 24 Monaten auseinander fällt bzw. den Geist aufgibt
- auf einem offenen Kommunikations-Standard (MQTT)
- einen Funkstandard ohne Begrenzung (1%-Regel bei 884MHz) beruht.
- halbwegs gut aussieht. (Wenn ich da an manche Rauchmelder denke fühlt man sich an Raumschiff Orion erinnert)
im "normalen" betrieb sollte die 1%-regel keine probleme bereiten, denke ich.
mehr probleme gibt es, wenn es hier keine regeln gibt.
siehe wlan.
Zitat von: Christoph Morrison am 03 November 2020, 10:12:07
Was für ein Konzept meinst du? Die HmIP-HAP haben kürzlich ein Firmware-Update bekommen, mit dem man sie wie ein HMLANGW einsetzen kann. Ich hab mir gleich mal ein paar Silvercrest-gelabelte für etwa 15-20€ pro Stück besorgt, unschlagbar gegenüber den HMLANGW.
Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.
Zitat von: ronzo am 03 November 2020, 10:23:28
Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.
Warum so "teuer" und nicht einen ESP mit serial-Bridge (oder hinge der PI dann per LAN dran?)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 03 November 2020, 10:25:14
Warum so "teuer" und nicht einen ESP mit serial-Bridge (oder hinge der PI dann per LAN dran?)...
Gruß, Joachim
Raspberrys liegen hier rum wie Sand am Meer.... (Habe mir testweise so ein USR TCP232-Teil bestellt, liegt aber ungenutzt herum, da ich keine Ahnung habe was ich da abgesehen vom PCB noch alles zusätzlich benötige...) Habe 3 LAN-GWs auf dieser Basis, die alle per LAN angebunden sind.
fang bloss nicht mit esp/wlan an.
Naja, ob nun ein PI per WLAN oder ein ESP per WLAN ist wohl egal... ;)
Wie geschrieben, wenn per LAN, dann ein PI...
Und es sind ja nicht nur die Anschaffungskosten sondern auch der Betrieb...
...ein ESP ist schon deutlich genügsamer...
Aber: deine Stromrechnung... ;)
Zitat
USR TCP232
Wichtig ist halt, dass max. 3,3V kommen sowohl bei Versorgung als auch bei den Pegeln!
Ansonsten: Pegelwandler! (oder Widerstandsteiler)
Gruß, Joachim
WLAN und Pi sind ein eigenes Thema, da sind esp deutlich stabiler (und können auch besser einen Stromausfall verkraften)
Aber nochmal zurück zu HmIP. Geht doch auch mit nem Raspberry, demselben PCB? und piVCCU und entsprechender Firmware. Hätte ich dann praktisch ein LanGW für HmIP oder kann ich davon nur ein Stück einsetzen (anstatt wie jetzt 3 HmLanGws)?
Zitat von: MadMax-FHEM am 03 November 2020, 10:35:28
Aber: deine Stromrechnung... ;)
Die Raspberries sind bei meiner Anzahl an Elektrogeräten schon wurscht... da würd ich mir höchstens einen kleinen esoterischen Betrag sparen.
Zitat von: ronzo am 03 November 2020, 10:23:28
Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.
Dann haben wir wohl unterschiedliche Definitionen von "simpel". Simpel ist für mich: Ich kaufe ein Gerät für 15€, drücke in der CCU3 und auf dem Gerät eine Taste und das wars.
Nicht dass du mich falsch verstehst, ich löte hier auch Zeugs und hab DIY-HM-Devices, aber simpel sind die nicht. Was genau da Gefrickel musst du mir, auch als Nicht-HmIP-Fanboy, doch noch mal erklären.
Zitat von: Christoph Morrison am 03 November 2020, 10:41:15
Dann haben wir wohl unterschiedliche Definitionen von "simpel". Simpel ist für mich: Ich kaufe ein Gerät für 15€, drücke in der CCU3 und auf dem Gerät eine Taste und das wars.
Nicht dass du mich falsch verstehst, ich löte hier auch Zeugs und hab DIY-HM-Devices, aber simpel sind die nicht. Was genau da Gefrickel musst du mir, auch als Nicht-HmIP-Fanboy, doch noch mal erklären.
Ich habe mich anfangs nicht vollständig meinen Standpunkt dargelegt. Habe jetzt 3 Raspberries mit dem PCB, die als HmLanGws agieren. Für HmIP würde ich das genauso auf Raspberry-Basis bevorzugen, da der eine oder andere Raspberry noch Zusatzaufgaben wahrnimmt (z.B. HUEBridge, oder BT LE Presence Check, ...). Für HmIP hätte ich gerne ein genauso gut funktionierendes Setup auf Raspberry-Basis.
Was ich bei Homatic so "toll" fand, war die Heizungssteuerung. Ventile an die Heizung, an CCU2 paaren und Profil einstellen. Eventuell (Meistens) die externe Steuerung/Sensor dran, Verbinden und das war es ....
Da ich hier teilweise mehr als ein Heitzkörper steuern muß, also mehrere pro Raum, geht so etwas auch per ZWAVE? Oder muß man da in FHEM "basteln"?
Zitat von: Wernieman am 03 November 2020, 10:47:35
Was ich bei Homatic so "toll" fand, war die Heizungssteuerung. Ventile an die Heizung, an CCU2 paaren und Profil einstellen. Eventuell (Meistens) die externe Steuerung/Sensor dran, Verbinden und das war es ....
Da ich hier teilweise mehr als ein Heitzkörper steuern muß, also mehrere pro Raum, geht so etwas auch per ZWAVE? Oder muß man da in FHEM "basteln"?
Na ja, wo beginnt "basteln"?
"Theoretisch" müßte es auch Thermostatköpfe geben, die Profile verwalten können - praktisch gesehen habe jedenfalls ich die aber noch nicht, und das "Format", in dem man Profile übermitteln muss, ist auch "speziell"...
Aber eine ganze Anzahl von ZWave-Thermostaten (auch verschiedener Hersteller) in eine structure packen und die z.B. mit WeekdayTimer+weekprofile steuern, das sollte problemlos gehen, und auch "vituelle Raumtemperatursensoren" werden prinzipiell unterstützt - nur eben auf andere Weise "frickelig" wie bei CUL_HM (mit IP geht das afaik bisher nicht). (Oder je einen WDT für je einen Thermostaten; geht genauso und via weekprofile kann man auch komfortabel umschalten).
Kurz: Es ist anders, die Thermostate laufen nicht autonom (auf einem Wochenprogramm) und manchmal ist das Verständnis für die Abläufe verbesserungsfähig (siehe aktuelle Diskussion zum Spirit), aber prinzipiell ist es kein wirkliches Problem, wenn man FHEM an sich im Griff hat...
Zitat von: ronzo am 03 November 2020, 10:45:10
Ich habe mich anfangs nicht vollständig meinen Standpunkt dargelegt. Habe jetzt 3 Raspberries mit dem PCB, die als HmLanGws agieren. Für HmIP würde ich das genauso auf Raspberry-Basis bevorzugen, da der eine oder andere Raspberry noch Zusatzaufgaben wahrnimmt (z.B. HUEBridge, oder BT LE Presence Check, ...). Für HmIP hätte ich gerne ein genauso gut funktionierendes Setup auf Raspberry-Basis.
Die HM-MOD-RPI-PCB unterstützt, wie ich auch erst kürzlich gelernt habe, ebenfalls HmIP. Ich habe nur noch keine Lösung gefunden (und auch nicht richtig gesucht), wie man einen RPI mit HM-MOD-RPI-PCB als abgesetztes LAN-GW für Hm-Classic und HM-IP nutzen kann. Alternativ könnte man natürlich eine eigene CCU3-Instanz mit was auch immer machen und die dann über FHEM/HMCCU koppeln.
Vertragen sich mehrere CCU3-Instanzen (z.B. Pi mit piVCCU) bei HmIP?
Moin,
nach meinem Kenntnisstand kann man zumindest mit Raspberrymatic einen Pi mit dem HM-MOD-RPI-PCB als abgesetztes Funkmodul für Homematic (ohneIP) nutzen. Klingt etwas schizophren. Ein Raspberrymatic mit HM-MOD-RPI-PCB funktioniert als Gateway für Homematic classic und Homematic IP. Setzt man einen Pi mit demselben Modul als Langateway ein funktioniert die Reichweitenvergrösserung nur für Homematic Classic. Für Homematic IP müsste man einen IP Access-Point mit einer speziellen Firmware versehen und als Reichweitenverlängerung einsetzen. Siehe auch Doku zu rasperrymatic https://github.com/jens-maus/RaspberryMatic/wiki (https://github.com/jens-maus/RaspberryMatic/wiki) Hier unter Tipps und Tricks: HAP als HMIP-Gateway und unter Experten Features LAN-Gateway Betrieb. Ein solche Konstrukt lässt sich dann allerdings nur über das HMCCU Modul in FHEM einbinden.
@ronzo:
Es gibt für HMIP aktuell keine LAN-GW auf Raspberry-Basis. Es gibt die bereits angesprochene Möglichkeit mit den HAPs, wobei dann aber RPI-RF-MOD (als Hauptfunkmodul) zwingende Voraussetzung ist.
Das Hauptfunkmodul kann wiederum über LAN und HB-RF-ETH (https://homematic-forum.de/forum/viewtopic.php?f=76&t=60150) abgesetzt werden. Das Konstrukt HB-RF-ETH + RPI-RF-MOD oder HB-RF-ETH + HM-MOD-RPI-PCB ist dann auch eine Art LAN-GW, das wird aber nur 1x pro CCU unterstützt.
Beide Möglichkeiten kann man auch kombinieren, sofern RPI-RF-MOD verwendet wird.
Habe auch Homematic für die Heizkörper und ansonsten mit einigem herumexperimentiert.
Was mir gut gefällt und was ich ausbauen werde ich Zigbee. Davon habe ich derzeit Leuchten und Fensterkontakte und Schalter im Einsatz. Das mit DECONZ. Das gefällt mir sehr gut, weil es ziemlich problemlos läuft und durch das Mesh eine gute Verbindung fördert. Und das ganze ist -wie schon erwähnt- ein Standard, man ist also nicht von einer Firma abhängig. Preis-Leistungsverhältnis ist auch gut. Weiß allerdings nicht, ob es da auch Thermostate von gibt.
An Leuchten habe ich OSRAM derzeit und an Rest von Aqara (Schalter) bzw. Dresden (DECONZ-Stick).
Zitat von: guhu am 03 November 2020, 12:08:03
Weiß allerdings nicht, ob es da auch Thermostate von gibt.
Gibt es zumindest einen, der auch von einzelnen FHEM-Usern verwendet wird: die ZigBee-Variante von dem Spirit. Gibt es auch attrTemplate für bei HUEDevice und MQTT2_DEVICE (falls wer das mit zigbee2mqtt verwenden will).
Die Einschränkungen sind aber afaik so ziemlich dieselben wie bei der ZWave-Variante (auch wenn das evtl. anders beworben wird).
Es gibt auch eine ganz gute "Datenbank" zu dem ZigBee-Zeug, der "(Wand-)Thermostate-Teil" ist hier zu finden: https://zigbee.blakadder.com/hvac.html (https://zigbee.blakadder.com/hvac.html) (ergo: es gibt sogar Wandthermostate in ZigBee...).
Ich hänge mich mal hier dran, da ich ebenfalls umsteigen muss. Mein HM-Wassersensor hat den Geist aufgegeben und eine CCU2 habe ich aus einer Update-Aktion für lau bekommen. Idee war jetzt, die CCU2 als IO-Device für HmIP zu nutzen (das sollte mit HMCCUkein Problem sein) und mit einem HmIP-SWD zu beginnen. Leider übersteig die Auswertung der Readings des Sensors dann meinem Horizont :(
1.ALARMSTATE, 1.MOISTURE_DETECTED, 1.WATERLEVEL_DETECTED finden sich schon mal, jetzt brauche ich nur noch eine Alarmlösung (DebianMail bei Änderung des Alarmstate).
Die Readings hast Du doch schon, wo ist jetzt das Problem?
Ich dachte an ein notify (siehe unten), welches bei Änderung des Alarmstate eine Mail schickt. Blöderweise werden die Reading trotz ccuGetVars=60 nicht aktualisiert.
list water_alarm:
Internals:
CFGFN
DEF HmIP_SWD_00189BE98FF266:.ALARMSTATE:.*
{
my $alarmstate = ReadingsVal( "HmIP_SWD_00189BE98FF266", "ALARMSTATE","0");
my $feuchte = ReadingsVal("HmIP_SWD_00189BE98FF266", "MOISTURE_DETECTED","0");
my $wasser = ReadingsVal("HmIP_SWD_00189BE98FF266", "WATERLEVEL_DETECTED",0);
DebianMail('frank@xxx.yyy',"Alarm vom FHEM System","Alarmstatus: $alarmstate, Feuchte: $feuchte, Wasser: $wasser","");}
FUUID 5fa174be-f33f-6cf2-a6a9-dc0382992e13d8b0
NAME water_alarm
NOTIFYDEV HmIP_SWD_00189BE98FF266
NR 72048
NTFY_ORDER 50-water_alarm
REGEXP HmIP_SWD_00189BE98FF266:.ALARMSTATE:.*
STATE active
TYPE notify
Helper:
DBLOG:
state:
logdb:
TIME 1604428061.85105
VALUE active
READINGS:
2020-11-03 19:27:41 state active
Attributes:
Und jetzt noch ein list von HmIP_SWD_00189BE98FF266, bitte.
aber gern: (vorsicht, ist länger)
Internals:
DEF 00189BE98FF266
FUUID 5fa046dc-f33f-6cf2-65e5-2a1efb872527c5d9
IODev d_ccu
NAME HmIP_SWD_00189BE98FF266
NR 226
STATE ???
TYPE HMCCUDEV
ccuaddr 00189BE98FF266
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SWD 00189BE98FF266
ccutype HmIP-SWD
channels 3
statevals devstate
Helper:
DBLOG:
0.CONFIG_PENDING:
logdb:
TIME 1604428634.17115
VALUE false
0.DUTY_CYCLE:
logdb:
TIME 1604428634.17115
VALUE false
0.ERROR_CODE:
logdb:
TIME 1604428634.17115
VALUE 0
0.ERROR_NON_FLAT_POSITIONING:
logdb:
TIME 1604428634.17115
VALUE false
0.INSTALL_TEST:
logdb:
TIME 1604428634.17115
VALUE true
0.LOW_BAT:
logdb:
TIME 1604428634.17115
VALUE false
0.OPERATING_VOLTAGE:
logdb:
TIME 1604428634.17115
VALUE 0.000000
0.OPERATING_VOLTAGE_STATUS:
logdb:
TIME 1604428634.17115
VALUE 0
0.RSSI_DEVICE:
logdb:
TIME 1604428634.17115
VALUE 0
0.RSSI_PEER:
logdb:
TIME 1604428634.17115
VALUE 0
0.UNREACH:
logdb:
TIME 1604428634.17115
VALUE true
0.UPDATE_PENDING:
logdb:
TIME 1604428634.17115
VALUE false
1.ALARMSTATE:
logdb:
TIME 1604428634.17115
VALUE false
1.MOISTURE_DETECTED:
logdb:
TIME 1604428634.17115
VALUE false
1.WATERLEVEL_DETECTED:
logdb:
TIME 1604428634.17115
VALUE false
hmstate:
logdb:
TIME 1604428634.17115
VALUE unreachable
READINGS:
2020-11-03 19:37:14 0.CONFIG_PENDING false
2020-11-03 19:37:14 0.DUTY_CYCLE false
2020-11-03 19:37:14 0.ERROR_CODE 0
2020-11-03 19:37:14 0.ERROR_NON_FLAT_POSITIONING false
2020-11-03 19:37:14 0.INSTALL_TEST true
2020-11-03 19:37:14 0.LOW_BAT false
2020-11-03 19:37:14 0.OPERATING_VOLTAGE 0.000000
2020-11-03 19:37:14 0.OPERATING_VOLTAGE_STATUS 0
2020-11-03 19:37:14 0.RSSI_DEVICE 0
2020-11-03 19:37:14 0.RSSI_PEER 0
2020-11-03 19:37:14 0.UNREACH true
2020-11-03 19:37:14 0.UPDATE_PENDING false
2020-11-03 19:37:14 1.ALARMSTATE false
2020-11-03 19:37:14 1.MOISTURE_DETECTED false
2020-11-03 19:37:14 1.WATERLEVEL_DETECTED false
2020-11-03 19:37:14 hmstate unreachable
hmccu:
devspec 00189BE98FF266
dp:
0.CONFIG_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTY_CYCLE:
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_CODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_NON_FLAT_POSITIONING:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
OSVAL false
OVAL false
SVAL false
VAL false
0.OPERATING_VOLTAGE:
OSVAL 0.000000
OVAL 0.000000
SVAL 0.000000
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.RSSI_DEVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.RSSI_PEER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UNREACH:
OSVAL true
OVAL true
SVAL true
VAL true
0.UPDATE_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
1.ALARMSTATE:
OSVAL false
OVAL false
SVAL false
VAL false
1.MOISTURE_DETECTED:
OSVAL false
OVAL false
SVAL false
VAL false
1.WATERLEVEL_DETECTED:
OSVAL false
OVAL false
SVAL false
VAL false
Attributes:
IODev d_ccu
room CCU_HM
EDIT: ein manuelles "get update" liefert sofort Werte.
Folgender Workaround hat mit jetzt weitergeholfen:
- Auf der CCU eine Systemvariable "Wasseralarm" definieren
- auf der CCU ein Programm zusammenklicken dass bei Änderung die Variable setzt (wahr/falsch)
- Die Variable wird durch FHEM korrekt im Minutentakt (ccugetvars=60) korrekt ausgelesen, darauf kann jetzt getriggert werden
Evtl. hilft das auch anderen bei Problemen mit HmIP-Geräten...
Dein notify greift auf folgendes zu: HmIP_SWD_00189BE98FF266:.ALARMSTATE:.*
Aber das Reading heißt doch: 1.ALARMSTATE
Damit wird dein notify nie getriggert. Gleiches gilt dann auch für deine ReadingsVal, oder?
Zitat von: pcbastler am 03 November 2020, 19:35:12
Ich dachte an ein notify (siehe unten), welches bei Änderung des Alarmstate eine Mail schickt. Blöderweise werden die Reading trotz ccuGetVars=60 nicht aktualisiert.
Wenn die Readings nicht aktualisiert werden, ist
- Der RPC Server nicht (richtig) konfiguriert
- Der RPC Server nicht gestartet
- ccureadingfilter falsch gesetzt
ccuGetVars ist nur für das regelmäßige Auslesen der CCU Systemvariablen gedacht.