fhem Instanz auf neue Hardware umziehen > HM Aktoren neu anlernen?

Begonnen von LittleNo, 08 Juni 2018, 08:07:40

Vorheriges Thema - Nächstes Thema

LittleNo

Ich möchte meine FHEM-Instanz von der Raspberry auf andere Hardware umziehen. Reicht es dabei die fhem.cfg zu kopieren damit angelernte Homematic-Aktoren wieder funktionieren? oder muss ich die dann alle neu anlernen? wie verhält es sich mit dem CUL?

Hollo

Wenn Du ein IO-Device mit identischer HMID hast, und Deine config weiter benutzt, sollte das problemlos funktionieren.
Die Geräte sind ja nur mit auf das passende IODev angewiesen. 
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Beta-User

Zitat von: LittleNo am 08 Juni 2018, 08:07:40
wie verhält es sich mit dem CUL?
Kommt drauf an, was es für ein CUL ist (Nachbau oder ATMega32U4), wie du ihn eingebunden hast, und welche USB-Geräte du ggf. noch nutzt. Ggf. mußt du die Definition anpassen. Kannst du ggf. vorher schon (jedenfalls für Debian-Derivat nach Debian-Derivat) auf die "by-id"-Variante ändern (siehe Tipp der Woche im Wiki).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

dieses hab ich: http://shop.busware.de/product_info.php/cPath/1_35/products_id/29

Auf der Raspberry habe ich bisher Ubuntu MATE und auf den neuen Server kommt auch Ubuntu, aber 18.04 in x64

Beta-User

Dann sollte "by-id" ohne Probleme gehen.
Müßte in etwa so aussehen, Details hier:
define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134

Da neulich hier im Forum darüber gestolpert ist:
Bei der Installation bitte den "Easy-Way" nach debian.fhem.de nehmen, bei 18.04 gibt es manche Pakete nur noch in neuerer Version, die in der manuellen Anleitung stehen.
Ich hoffe mal, das ist eine Server-Variante ohne GUI?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

ZitatIch hoffe mal, das ist eine Server-Variante ohne GUI?
ja

ZitatBei der Installation bitte den "Easy-Way" nach debian.fhem.de nehmen, bei 18.04 gibt es manche Pakete nur noch in neuerer Version, die in der manuellen Anleitung stehen.
Du meinst Pakete von denen fhem abhängig ist?

Beta-User

Zitat von: LittleNo am 08 Juni 2018, 15:22:55
Du meinst Pakete von denen fhem abhängig ist?
Jein, hatte mich etwas mißverständlich ausgedrückt. Es geht um Pakete, die bei Manual installation genannt sind, aber _nicht_ mehr (in der Form) verfügbar sind (anders heißen, bzw. durch neuere Versionen ersetzt wurden).

Der Easy-Way kann damit scheinbar gut umgehen, ansonsten muß man nachregeln: https://forum.fhem.de/index.php/topic,88427.0.html
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

So ich habe es jetzt gerade so gemacht (fhem mit "easy way" installiert, CUL angesteckt und die alte fhem.cfg rüber kopiert)

Es funktioniert auch (so mehr oder weniger, ich kann die HM-Aktoren alle steuern, aber irgendwie ruft er selbständig nicht immer den Status der Aktoren ab)

Bei der Anmeldung bekomme ich diese Meldung:

Messages collected while initializing FHEM:
./log/fhem.save: Please define CUL_0 first
Please define CUL_0 first

Beta-User

Zitat von: Beta-User am 08 Juni 2018, 13:46:28
Müßte in etwa so aussehen, Details hier:
Bist du danach vorgegangen?Oder hast du die alte CUL-Definition gelöscht und dann eine neue erstellt? (Dann ggf. die cfg editieren und den CUL nach oben packen vor die CUL_HM-Devices; backup vorher!) (Und ggf. gleich noch eine VCCU anlegen...)
Poste doch bitte die Ausgabe von list CUL_0 (FHEMWEB) und "ls -l /dev/serial/by-id" (an der Konsole)

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

ZitatBist du danach vorgegangen?Oder hast du die alte CUL-Definition gelöscht und dann eine neue erstellt?
weder noch, das CUL war ja schon definiert weil es in der alten cfg-Datei war, die ich auf die neue Kiste kopiert habe

list CUL_0:
No device named CUL_0 found

und:
hhsl@hhslserver:~$ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jun  9 20:50 usb-busware.de_CUL868-if00 -> ../../ttyACM0


Der Device-Name "ttyACM0" ist im neuen System identisch wie im alten

Beta-User

Zitat von: LittleNo am 09 Juni 2018, 23:21:09
Messages collected while initializing FHEM:
./log/fhem.save: Please define CUL_0 first
Please define CUL_0 first

Nach dieser Meldung ist davon auszugehen, dass es irgendwann mal ein Device mit diesem Namen gegeben hat.

Wenn das jetzt nicht mehr so ist, dürfte die Meldung daher kommen, dass irgendwo ein (anderes) Device definiert ist, das irgendwas mit dem ehemaligen "CUL_0" zu tun hat, z.B. weil es als IODev festgelegt ist. Das hat dann aber rein gar nichts mit dem Umzug zu tun, sondern war vorher schon so... Such doch einfach mal in der cfg nach "CUL_0", dann bekommst du das auch noch weg.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

hm das kommt in der fhem.cfg nur ganz am Anfang in genau dieser Meldung vor:

Zitatattr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd Messages collected while initializing FHEM:\
./log/fhem.save: Please define CUL_0 first\
Please define CUL_0 first\
\
Autosave deactivated
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

Und jein, ganz sauber funktioniert es nicht. Er hat von manchen Aktoren bis jetzt immernoch keinen Status abgefragt und das obwohl die auch schon geschaltet wurden.

Beta-User

...dann sollte es nach einem save und Neustart dann von selber verschwinden...
Was die fehlenden Stati angeht, habe ich keine definitive Idee, aber zwei Dinge, die ggf. ursächlich sein _könnten_:Zum einen ist ein CUL eben nur bedingt ein gutes IO für HomeMatic (siehe Wiki zu HM), zum anderen könnte es auch ein Stromproblem sein. Aber eigentlich würde ich so ein Problem eher vermuten beim Umzug _auf_ einen PI, du gehst aber ja den umgekehrten Weg.
Was ist das für eine Plattform? Sind das evtl. USB3-Anschlüsse? (Dann mal die 2-er testen, so vorhanden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

LittleNo

Zitat...dann sollte es nach einem save und Neustart dann von selber verschwinden...
ok, ist weg

ZitatZum einen ist ein CUL eben nur bedingt ein gutes IO für HomeMatic
halte ich nicht für die Ursache weil es vorher völlig fehlerfrei funktioniert hat

ZitatWas ist das für eine Plattform? Sind das evtl. USB3-Anschlüsse? (Dann mal die 2-er testen, so vorhanden).
ein Intel NUC, hat ausschließlich USB3

Beta-User

Zitat von: LittleNo am 10 Juni 2018, 10:18:35
ein Intel NUC, hat ausschließlich USB3
Kannst du die irgendwie auf USB2-Modus verstellen?
Zitat von: LittleNo am 10 Juni 2018, 10:18:35
halte ich nicht für die Ursache weil es vorher völlig fehlerfrei funktioniert hat
Fully agreed; hatte früher auch lange nur einen CUL mit Standardfirmware und nie irgendwelche Probleme wahrgenommen!Andererseits: Manchmal gibt es seltsame Effekte, wenn der Server zu schnell ist; wäre nicht das erste Mal, dass eine Kombination mit was neuem Fehler aufdeckt.

Aber wenn sonst alles soweit läuft, ist die Frage, wieviel Sinn weitere Ursachenforschung macht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors