Anleitung MAXLAN auf CUL_MAX umstellen ?

Begonnen von dt2510, 20 November 2019, 12:42:29

Vorheriges Thema - Nächstes Thema

dt2510

Ich habe Probleme mit meinem MAX Cube. MAXLAN verursacht durch Polling Hänger von ~6sek/Minute in FHEM. Daher würde ich gerne einen 2. Cube in einen CUL umflashen (Anleitung steht ja hier im Forum). Soweit sollte das kein Problem sein, allerdings ist mir die nachfolgende Vorgehensweise noch unklar.

Wie ziehe ich dann die bereits angelernten MAX Devices um und wie lerne ich mit dem CUL später neue Geräte an und erstelle Räume, Verknüpfungen und Zeitpläne ?
Gibt es hierzu auch eine Schritt für Schritt Anleitung ?

Wzut

Für den Wechsel MAXLAN zu CUL_MAX gibt es zwei Möglichkeiten :
a. der lange harte Weg (steht auch so im Wiki ) via Werksreset für jedes Device und neu pairen mit CUL_MAX und dessen ID
b. der kurze einfache Weg : Internal addr von MAXLAN als Parameter für CUL_MAX
( Lies dafür mal die letzten hier aktuellen Freds  da das jetzt fast schon einmal pro Woche hochkommt )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

dt2510

also flashen ... CUL_MAX mit MAXLAN ID und alles funktioniert wie gehabt ?

Wzut

Radio Eriwan : "Im Prinzip ja, aber ..."
D.h. am Besten das MAXLAN Device ganz vom Netz nehmen und mal bei einem MAX Device das IODevice vom MAXLAN auf das CUL_MAX Device ändern.
Mit diesem geänderten Device testen. Gibt es Probleme sind nur zwei Schritte zum zurück gehen nötig.
Klappt alles dann die anderen MAX Geräte auch editieren und dann kommt der gemeine Teil :
In der fhem.cfg soll das CUL und CUL_MAX Device vor die MAX Geräte , also dahin wo zuvor das nun nicht mehr benötigte MAXLAN Device war.
Gemein ist der Teil insofern das es am einfachsten ist dafür die fhem.cfg zu editieren. Wird von vielen Leuten quasi als Gotteslästerung empfunden,
ist IMHO aber der einzige Weg ausser alles zu löschen und in der richtigen Reihenfolge neu anzulegen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Gab es da nicht einen dritten Weg?

(Der Modulautor baut das so um, dass es gegen die Reihenfolgeproblematik immun wird... ;) . Aus dem Kopf: Die Initialisierung der Clients erst dann fertigstellen, wenn $init_done; am einfachsten via InternalTimer, denn alle Timer werden erst ausgeführt, wenn die Konfiguration komlett geladen wurde).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dt2510

Zitat von: Wzut am 20 November 2019, 14:08:42
Klappt alles dann die anderen MAX Geräte auch editieren und dann kommt der gemeine Teil :
In der fhem.cfg soll das CUL und CUL_MAX Device vor die MAX Geräte , also dahin wo zuvor das nun nicht mehr benötigte MAXLAN Device war.
Gemein ist der Teil insofern das es am einfachsten ist dafür die fhem.cfg zu editieren. Wird von vielen Leuten quasi als Gotteslästerung empfunden,
ist IMHO aber der einzige Weg ausser alles zu löschen und in der richtigen Reihenfolge neu anzulegen.

Ich ändere auch vieles in der fhem.cfg direkt, weil es - gerade bei Massenänderungen - sehr viel einfacher ist. Man sollte natürlich die Struktur der fhem.cfg kennen und einigermaßen wissen, was man macht ...

Wzut

Zitat von: Beta-User am 20 November 2019, 14:17:28
(Der Modulautor baut das so um, dass es gegen die Reihenfolgeproblematik immun wird... ;)
Klar der Modulautor (in dem Fall ich ab heute Abend) kann alles und wird es auch machen, aber noch müssen wir ja von der aktuellen Situation aus gehen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

dt2510

#7
Ich versuche dann mal nochmal alles zusammenzufassen ...

- Flashen des Cubes nach Anleitung (J1 zum löschen der original FW usw. ...)
- Anlegen der Devices vor den vorhandenen MAX Devices (aus dem Wiki)

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456


wobei /dev/ttyACM0 wohl am Besten vorher zu prüfen wäre (auf dem Device hängt aktuell mein ZWave Dongle - der Cube hängt dann per USB am FHEM Server und nicht mehr per LAN im Netz oder ?).
123456 entspräche dann wahrscheinlich der MAXLAN ID.

- MAXLAN entfernen (Hardware aus dem Netz oder das Device aus FHEM ?)

Bei den MAX Devices muss jetzt (zum Test erst bei einem) das IODev auf "cm" (wie oben) geändert werden.


Eine Aussage im Wiki ist mir noch unklar ...

ZitatAnlernen per CUL
Das Anlernen funktioniert nur mit zurückgesetzten (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostat betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können nicht an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

Meine MAX Devices waren ja an einem Cube angelernt. Kann ich jetzt nur mitlesen oder funktionieren sie genauso wie zuvor inkl. setzen der desiredTemperature usw. ?

Wo ist eigentlich in der Definition die Verknüpfung zwischen CUL und CUL_MAX ?

Beta-User

 :) Klingt gut, nicht alle bekommen das so stressfrei hin wie dt2510 (oder können das überhaupt => configDB).

Für den Fall, dass du "schnellen Code" suchst (was ich fast nicht annehme), hier noch ein Link mit diversen Lösungen dazu.
https://forum.fhem.de/index.php/topic,48829.0.html

Es gab dazu auch einen anderen, längeren Thread, in dem sich Rudi tendenziell für die Timer-Lösung ausgesprochen hatte, den habe ich nur leider auf die Schnelle nicht gefunden. (Das Argument dafür habe ich leider auch vergessen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dt2510

Zitat von: Beta-User am 20 November 2019, 14:39:06
:) Klingt gut, nicht alle bekommen das so stressfrei hin wie dt2510 (oder können das überhaupt => configDB).

Ich habe bisher nur von Logfiles auf DbLog umgestellt. Konfigurationsdateien in lesbarer/editierbarer Form sind mir weitaus lieber als die Konfiguration in der Datenbank.
So ist auch z.B. ein neues Device sehr viel einfacher einzurichten:

- Device per autocreate erzeugen lassen
- Ähnliches Device (vom gleichen Typ) mit allen Attributen kopieren
- ID und Namen des Devices anpassen
- fertig

Über FHEMWEB muss ich mir erst alle Parameter bei einem anderen Gerät raussuchen, notieren (oder Screenshot) und bei dem neuen wieder einstellen.

Klar je nach Device ist etwas mehr vorher/nachher erforderlich, aber im Prinzip passt es so

Beta-User

Sorry, aber das "schneller" ist mMn. kein Argument... Das geht nämlich über FHEMWEB definitiv schneller, wenn man "RAW" nutzt:

RAW-Code vom "ähnlichen Device" aus der RAW-Anzeige nehmen (oder via list -r <device> ausgeben lassen), anpassen und dann entweder direkt in das offene RAW-Editor-Fenster eingeben oder das "plus" verwenden, "execute" und gut ist.

Vorteile:
- Es wird gleich eine Fehlerprüfung durchgeführt :P
- man braucht keinen Restart (alle anderen Devices bleiben aktuell);(- die Alternaitve rereadcfg kann man eh' nicht mehr empfehlen, da steigen manche Module aus, z.B. MQTT_GENERIC_BRIDGE oder AutoShuttersControl).

Aber jeder wie er kann und mag  :-* .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dt2510

Zitat von: Beta-User am 20 November 2019, 15:09:09
Sorry, aber das "schneller" ist mMn. kein Argument... Das geht nämlich über FHEMWEB definitiv schneller, wenn man "RAW" nutzt:

Das hab' ich noch nie genutzt - guter Tip ! :)

rudolfkoenig

ZitatEs gab dazu auch einen anderen, längeren Thread, in dem sich Rudi tendenziell für die Timer-Lösung ausgesprochen hatte, den habe ich nur leider auf die Schnelle nicht gefunden. (Das Argument dafür habe ich leider auch vergessen).
NotifyFn wird fuer jedes global Event aufgerufen, und muss auf global:INITIALIZED pruefen.
Man kann zwar NotifyFn nach dem ersten Aufruf entfernen, die Funktion wird dann noch komplizierter.
Timer wird nur einmal aufgerufen, und muss nichts pruefen.
Falls man als Zeit 0 angibt, dann wird die Funktion bei der naechsten Moeglichkeit (hier: nach Einlesen der fhem.cfg & fhem.state) aufgerufen.

Die Reihenfolge kann man auch mit {$defs{deviceToMove}{NR} = X } setzen, wobei X die NR des Geraetes ist, wohin man es verschieben will.
Wenn das Modul IODev mit der Funktion AssignIoPort zuweist, dann wird nach dem kompletten Einlesen von fhem.cfg nochmal eine Runde fuer die nicht gefundenen Geraete gedreht.
Insofern sollte das Verschieben _eigentlich_ unnoetig sein.

Beta-User

Zitat von: dt2510 am 20 November 2019, 15:28:24
Das hab' ich noch nie genutzt - guter Tip ! :)
Immer wieder gerne ;D .



@Rudi:
Danke für die erhellenden Worte, ist eigentlich naheliegend (ich fand das beim Umbau von WeekdayTimer neulich auch deutlich einfacher umzusetzen (da gibt's keine X_notify) und habe das schon allein aus diesem Grund als simple und funktionale Lösung im Kopf.

Wie ist das eigentlich bei rereadcfg? Da wird ja das define neu gelesen und daher dann auch Timer usw. neu gesetzt. Wer da mit X_notify arbeitet, bekommt das auch via global:INITIALIZED (oder ist u.a. das das Problem von AutoShuttersControl, dass das Event anders heißt)?
(Ist auch nicht wichtig, denn zum einen spricht sich das mit RAW immer mehr rum, es gibt tendenziell mehr Probleme, wenn man das nutzt als es löst. Von daher heißt eigentliche Frage: Wäre es nicht an der Zeit, rereadcfg auf deprecated zu setzen?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Ich fang mal hinten an :
Was ich so auf die Schnelle in 10_MAX sehe ist :
attr IODev wird geprüft beim jedem Set Kommando, dürfte damit eigentlich beim define durchlaufen auch wenn es erst später in der fhem.cfg steht.
Werde ich aber heute Abend auch nochmal probieren damit da auch Klarheit herrscht.

@dt2510 , das MAX Wiki ist IMHO hoffnungslos veraltert und an einigen Stellen einfach falsch & schlecht.
Wenn du beim CUL die Wahl hast :
a. umgeflashter CUBE -> USB oder LAN , nimm zuerst USB ( ich vermute da via LAN noch eine Zeitproblem beim Pairing )
b. echter USB CUL -> CUL FW vs. a-culfw , hier bin ich jetzt jahrelang problemlos mit einer uralt CUL FW unterwegs gewesen.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

rudolfkoenig

ZitatWäre es nicht an der Zeit, rereadcfg auf deprecated zu setzen?
Das bedeutet auch das Editieren der fhem.cfg in FHEMWEB zu entfernen.
Mir selbst ist das egal (mAn halten sich die Probleme deswegen im Grenzen), es sollte im groesseren Kreis abgestimmt werden.

Beta-User

Hmm, dass man das im größeren Kreis abstimmen sollte, ist klar, war nur als Anregung gemeint, evtl. im Rahmen eines featurelevel 5.10-releases...

Vielleicht wäre es eine Idee, in den Fällen, in denen der user das nicht über den Editor innerhalb FHEM indirekt anstößt einen (für die, die wissen, was sie tun abschaltbaren) Hinweis einzublenden, dass es empfohlen wird, lieber den RAW-Weg zu nehmen? (habe darüber auch noch nicht intensiv nachgedacht, stelle nur fest, dass es immer noch (durchaus erfahrene) Leute gibt, die diesen im pdf dargestellten rereadcfg-Weg gehen, weil sie den "abgesicherten" und direkten Weg nicht kennen, auch weil er da nicht auftaucht.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Hust ... habt ihr zwei vor den Fred zu kapern ? 
IMHO ist das für die Diskussion nicht nur der falsche Thread sondern auch das falsche Unterforum :D
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

dt2510

Ich habe gerade mal den 2. Cube geflasht aber noch eine Frage. Aktuell belegt mein ZWave Stick /dev/ttyACM0, ich gehe davon aus, dass der Cube dann als /dev/ttyACM1 erkannt wird (bin gerade nicht zuhause). Bleibt diese Reihenfolge immer gleich oder sollte ich eine 99-usb-serial.rules Datei anlegen und den Sticks über die Vendor/Product ID einen festen Namen z.B. ttyZWAVE, ttyMAX usw. zuordnen ?

Beta-User

Kann man über udev-rule machen. Einfacher (auch bei einem FHEM-Umzug irgendwann man auf ein anderes System) ist es mAn., die "by-id"-Methode zu nehmen (siehe Wiki "Mehrere USB-Geräte...").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

riker1

Hallo,

habe eigentlich nicht ganz verstanden warum der MAXLAN umgeflashed werden sollte.

Was sind denn die Vorteile von CUL_MAX?

Danke
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Wzut

Für mich persönlich waren das die Gründe :
1. Kein Alzheimer des CUBE mehr -> die org FW hat die unangenehme Eigenschaft öfters mal alle Geräte zu vergessen.
Da es von e3q selbst keine Backup / Restore Funktion gibt musste man wenn man faul ist (wie ich) auf ein JAVA Fremdprodukt ausweichen
(wird aber auch schon lange nicht mehr geflegt)
Mit der a-culfw auf dem Cube wird er dumm, d.h. da er keine Geräte mehr kennt, kann er auch keine mehr vergessen, den Job übernimmt FHEM.

2. Die Anbindung der MAX Geräte mittels MAXLAN fand ich nicht so überzeugend, vor allem das Geschüttel mit ondemand
(wobei der Verdacht schon mit der JAVA Software aufkam das "Fremdzugriffe" auf den Cube dessen Alzheimer noch förden)

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

don.redhorse

3. du brauchst keinen MAX Scanner mehr.

Ich nutze einen Fensterkontakt und FHEM um in der Küche die Dunstabzugshaube abzuschalten, wenn das Fenster geschlossen wird. Mit einem MAXLAN muss man recht oft pollen, mit einem CUBe bekommt der Sonoff via FHEM eigentlich sofort die Meldung das er abschalten soll wenn das Fenster geschlossen wird.

Cube-Alzheimer nervt aber auch, dreimal neu angelernt, zweimal mit 8 HTs scheinbar wird er vergesslicher wenn er sich mehr merken soll, nein, FHEM kann das einfach besser.

riker1

Hallo,

habe auch immer wieder Probleme mit dem MAXLAN.
Werde dann mal umstellen.

Kann doch aber auch einen CUL mit rfMode MAX nehmen, oder?

https://fhem.de/commandref.html#CUL_MAX

da steht nichts von der frequenz, ist das dann 868MHz?

Danke

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

don.redhorse

CUL läuft super. Habe seit einigen Jahren einen nanoCUL in Benutzung, keine Probs. Wenn du dir einen bauen willst, achte darauf was für einen Arduino du erwischt. Die meisten haben ein CHxxx Serialcontroller, oder einen Fake FTDI, meist muss man einen Lötpunkt nachsetzen, steht aber im Wiki. Platinen zum auflöten kannst du in der Bucht bekommen, ebenso die Sender/ Empfänger, auch da gibt es Fakes, ist im Wiki beschrieben.

Wzut

Zitat von: riker1 am 23 November 2019, 09:18:36
Kann doch aber auch einen CUL mit rfMode MAX nehmen, oder?
da steht nichts von der frequenz, ist das dann 868MHz?
a. ja kannst du wenn du den CUBE erst einmal noch inter Hinterhand behalten willst. Nach dem flashen gibt es kein zurück mehr für ihn
b. richtig , 868
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher