Anleitung MAXLAN auf CUL_MAX umstellen ?

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

Vorheriges Thema - Nächstes Thema

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