HomeMatic zieht um

[CatWeazle]

Hi Leutz,

meine FHEM Installation ist noch meine Erstinstallation, Alter ca. 2 Jahre.
Vieles ausprobiert und noch mehr wieder verworfen.

Jetzt wollte ich auf einem anderen Raspberry einen Neustart wagen.
Aktuelles stretch.img, Java 8, frisches FHEM 5.9 usw.

Grundeinstellungen, Schalt- und Timerfunktionen,  Dies und Das, alles gut .... .... läuft ... ...

Ja, jetzt kommt HomeMatic, wie ziehe ich damit um?
Auf dem Alten RPI ist alles eingerichtet und HM (nicht IP) läuft gut an einem V 1.67 nanoCUL868.

Kann ich einfach die define und attr der jetzigen FHEM Einrichtung im neuen RPI ein hämmern den nanoCul um stöpseln und alles ist gut?
Ist es so einfach ?

Ich habe keine VCCU installiert.

Besten Dank für eure Hilfe 

[Beta-User]

Im Prinzip: JA!

Ausnahme: Das IO (der CUL). Wie ist der definiert? Wie viele andere USB-Geräte gibt es?
Keines => no Action required
Trotzdem würde ich zur DEF mit "by-id" raten (siehe Wiki: mehrere USB-Geräte verwenden). Ist in fast allen Fällen stressfrei und kann auch noch auf dem Altsystem erfolgen.

RAW-Import ist bekannt?

[CatWeazle]

Hallo Beta-User,

klingt gut
Ja der CUL ist by-id eingebunden, der nano hat einen FT323RL mit SerialNo.

ooops, RAW Import, hmmm ne, da muss ich passen ?!?!?!?

Hilf mir mal bitte auf den Pott

[Beta-User]

Bitteschön...

https://wiki.fhem.de/wiki/Raw_definition

(Im Prinzip könnte man damit auch die ganze cfg auf einen Rutsch ins neue FHEM importieren...)
In dem Zusammenhang vielleicht auch hilfreich für's Altsystem:
list mit Optionen -r und -R, also z.B.

Code Auswählen Erweitern

list -r TYPE=CUL_HM

Code Auswählen Erweitern

list -r .*

Code Auswählen Erweitern

list -R CUL
(Aus alter Gewohnheit würde ich aber erst direkt nach global alle IO's reinpacken, dann die sonsitge Hardware und dann erst den Rest. Nach den physischen IOs kannst du auch präventiv eine VCCU definieren; nimm eine andere HmID, dann ist die erst mal nicht scharf geschaltet...)

[CatWeazle]

Hallo Beta-User,

okay, nein -r kannte ich nicht, aber gut, bedankt


JA, präventiv eine VCCU definieren, die wollte ich schon im Altsystem anlegen.
Nach dem Motto: niemals ein funktionierendes System ändern ... ... hab ich es aber nie gemacht.

Wie eine VCCU definiert wird muss ich mir mal ansehen, fürs neue System sicher eine gute Idee, zumal ich das HM_PCB Modul schon lange hier liegen habe, dann könnte das auch zum Einsatz kommen.

[Beta-User]

Es gibt beim Wechsel zu VCCU nur einen Punkt, auf den man achten muß: die Events ändern sich teilweise, z.B. "on (to VCCU)".
Du solltest also daher deine Event-Handler darauf prüfen, ob das relevant sein kann (kannst ja das neu-System mit dem HMUARTLGW nutzen, das unter die VCCU packen und schon mal experimentieren)...

[CatWeazle]

Hallo Beta-User,

ich habe bevor ich deinen letzten Beitrag gelesen habe auf mein Altsystem mit der original HM-ID eine VCCU nach Wiki eingerichtet.

Code Auswählen Erweitern



define VCCU CUL_HM 123456
attr VCCU model CCU-FHEM
attr VCCU IOList nanoCUL
attr VCCU IOgrp VCCU
attr VCCU subType virtual
attr VCCU webCmd virtual:update

attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU

Nach einem Neustart funktioniert scheinbar alles ganz normal.

Jetzt kommst du mir mit einem Events Dingens um die Ecke ?!?!?
Nein im Ernst, wie prüfe ich dieses mögliche Event-Handler Problem?

Besten Dank ... ...

 

[betateilchen]

Jetzt kommst du mir mit einem Events Dingens um die Ecke ?!?!?
Nein im Ernst, wie prüfe ich dieses mögliche Event-Handler Problem?

Lass Dich nicht verrückt machen. Zieh erstmal komplett um und teste, ob alles funktioniert. Bisher sieht doch alles gut aus.

[CatWeazle]

Okay,

obwohl mich dieses mögliche Event-Handler Problem jetzt doch interessiert. 

Ich zieh schon mal den Kopf ein ... ... ...

Nach dem ich nun auf dem Altsystem endlich eine VCCU installiert habe, sehe den Vorteil so einer VCCU noch nicht ?!?!?!
Gut, es ist möglich mehrere Geräte (sogar dynamisch) zur Kommunikation mit den HM Endgeräten zu verwenden, nanoCUL und den HM_PCB usw.

Von der VCCU sehe ich so direkt nichts.

[Pfriemler]

VCCU kann noch ein paar Kleinigkeiten mehr als ein reines HM-IO-Gerät. Es gibt so oder so keinen vernünftigen Grund, ohne zu arbeiten. Spätestens mit einem zweiten IO wird es unverzichtbar. Und zu sehen bekommt man davon in der Regel genauso wenig wie von HMInfo, obwohl das noch viel hilfreicher ist.

Das "mögliche Event-Handler-Problem" dürfte keines sein, wenn Du in deinen Definitionen bisher sauber gearbeitet hast, also das regex für das auslösende Event in der aufzurufenden Routine (notify, DOIF, ...) allgemeingültig formuliert ist, was in 99,x % aller Beispiele und Demos der Fall ist.
Ein kurzer Tastendruck auf meinen Button "Eingang6Taster_RightUp" liefert bsp. das Event "Short 1_149 (to vccu)", was ich mit "Eingang6Taster_RightUp:Short.*" einfach abfange - es ist völlig egal, ob da hintendran "(to vccu)" oder "(to myCUL)" steht.

Wichtig: Behalte beim Übertragen der VCCU auf das neue System die hmId bei. Sonst musst Du alle Geräte neu anlernen.

[CatWeazle]

Hallo Pfriemler,

danke für die beruhigende Antwort.

Der Umzug klemmt noch ein wenig aber es geht voran, eins nach dem anderen.
Bis eben hat mich noch die HA-Bridge geärgert, nachdem ich dann von V5.2.1 bis 5.2.2RC3 keinen Erfolg hatte, habe ich fürs Erste die 4.5.6 installiert, löppt !

Aktuell versuche ich den GPIO Busmaster für meinen DS18B20 zu definieren, unter FHEM 5.9 18627 2019-02-18 funtioniert das scheinbar anders als unter 15377 2017-11-01.

Ah, das wird ... ...

[Beta-User]

Das "mögliche Event-Handler-Problem" dürfte keines sein, wenn Du in deinen Definitionen bisher sauber gearbeitet hast, also das regex für das auslösende Event in der aufzurufenden Routine (notify, DOIF, ...) allgemeingültig formuliert ist, was in 99,x % aller Beispiele und Demos der Fall ist.
Ein kurzer Tastendruck auf meinen Button "Eingang6Taster_RightUp" liefert bsp. das Event "Short 1_149 (to vccu)", was ich mit "Eingang6Taster_RightUp:Short.*" einfach abfange - es ist völlig egal, ob da hintendran "(to vccu)" oder "(to myCUL)" steht.

Nope, ich hatte genau das umgekehrte Problem, dass eine m.E. "unsaubere" Definition wie "Eingang6Taster_RightUp:Short.*" dazu geführt hat, dass notify's _mehrfach_ getriggert wurden: Die Schalter sind nämlich bei mir teilweise mit anderen Aktoren gepeert... Macht dann z.B. 2 statt einem Event usw.. Also verwende ich in der Regel den "Short.*(to VCCU)"-Event, um genau das zu vermeiden.

[betateilchen]

Nope, ich hatte genau das umgekehrte Problem, dass eine m.E. "unsaubere" Definition wie "Eingang6Taster_RightUp:Short.*" dazu geführt hat, dass notify's _mehrfach_ getriggert wurden: Die Schalter sind nämlich bei mir teilweise mit anderen Aktoren gepeert... Macht dann z.B. 2 statt einem Event usw.. Also verwende ich in der Regel den "Short.*(to VCCU)"-Event, um genau das zu vermeiden.

Deshalb verwende ich den Event, der beim Drücken eines Tasters nur einmal auftritt, egal wieviele Aktoren damit gepeert sind:

Code Auswählen Erweitern


2019-02-24 16:38:21 CUL_HM HM_39D35A HM_39D35A_Btn_07 Short
2019-02-24 16:38:21 CUL_HM HM_39D35A_Btn_07 Short 1_206 (to wz_Ventilator)


in diesem Fall also die erste Zeile:

Code Auswählen Erweitern

define HM_39D35A_notify_1 notify HM_39D35A:HM_39D35A_Btn_07.Short {}

[Beta-User]

Deshalb verwende ich den Event, der beim Drücken eines Tasters nur einmal auftritt, egal wieviele Aktoren damit gepeert sind:

Jup, auch diese Variante ist hier im Einsatz.

Es ging eigentlich vorrangig darum, darauf hinzuweisen bzw. zu verdeutlichen, dass die .*-Variante eben genau _nicht eindeutig_ ist und welchen Hintergrund die in Zweifel gezogene Anmerkung weiter oben hatte...

[CatWeazle]

Hi Leutz,

also, ich möchte an die beiden FHEM Giganten nur nochmal ganz vorsichtig eine Frage stellen.
Bezieht sich das Event-Problem nur auf notify's & doifs, wovon ich eigentlich ausgehe.

Wenn dem so ist, habe ich kein Problem, da ich für HM keines von beiden angelegt habe