MAX! Fensterkontakte per CUL MAX! lesen + MAX! Devices untereinander per Cube

[stobor]

Hallo,
ich nutze derzeit meine MAX! Komponenten per Cube und FHEM. Ich habe allerdings den Eindruck, das diese Integration FHEM ein wenig bremst.
Da ich derzeit in FHEM nur an den Zuständen der Fensterkontakte interessiert bin, frage ich mich, ob man nicht die Cube aus FHEM nutzt, sondern mit dem CUL dem MAX! Funkverkehr lauscht und nur auf die Kontakte reagiert. Hat damit schon jemand Erfahrung? Ich würde ungern alle MAX! Komponenten von der Cube löschen und alles neu in FHEM anlernen und nur noch über FHEM steuern. Kann man also das komplette MAX! System weiter über die Cube laufen lassen und nur die Funksignale der Fensterkontakte per CUL abfangen und auswerten? Ich würde dann auch die MAX! Cube aus der fhem.cfg entfernen.
Danke für euer Feedback.

[Tobias]

sollte gehen, mein MAX-system arbeitet komplett per CUL ohne Cube und fhem bekommt den gesamten Funkverkehr sofort mit, insbes. der Fensterkontakte

[stobor]

Aber ich möchte ja MAX! weiterhin autark über die Cube laufen lassen und nur die Fensterkontakte per fhem/CUL belauschen.
Ist das auch möglich, wenn die doch noch zur Cube gepaired sind?

[Tobias]

ja, ist möglich

[stobor]

Ok, dann werde ich das mal probieren und mich mit dem Ergebnis melden.

Ich nutze noch ne alte CUL Firmware. Sollte die mal aktualisiert werden? Was wäre da sinnvoll? ich habe mehrere Firmware-Stände gefunden (siehe Thread: Link)

Wie muss der CUL denn in der fhem.cfg eingebunden werden, damit er "nur" auf MAX! lauscht? FS20 funktioniert doch weiterhin parallel, oder?

Danke

[marc2]

Hi !

Meine Einbindung sieht wie folgt aus:

#
# CUNO MAX
#
define CUNO2 CUL cuno2:2323 0000
attr CUNO2 rfmode MAX
define cm CUL_MAX 123456

Zu Pairen ist nichts, da ja nur "gehorcht" werden soll. Da in Deinem Falle ja es alles mit dem CUBE
gepaired sein sollte, geht das auch nicht. Ein Shutter kann - meines Wissens nach - immer
entweder nur mit dem CUBE oder dem CUL (bei mir CUNO) gepaired sein.

Ich habe sogar einen Mischbetrieb. Da wo die Shutter auch einen Heizkörper steuern, sind sie
mit dem CUBE gepaired (und der CUNO schneidet nur die Events mit). Dort, wo ich nur ein Fenster
oder eine Tür überwachen will, ist der Shutter direkt mit dem CUNO gepairt.

In Sachen Firmware wirst Du Dir den aktuellen SVN Stand besorgen müssen befürchte ich.

By the way. Wenn Du die Events der Shutter sinnvoll auswerten willst, muss das Attribute
"event-on-change-reading" entsprechend gesetzt sein. Anders als ein vergleichbarer HM
threeStateSensor brüllen die MAX-Shutter nämlich nicht nur die eigentliche Änderung, sondern
in undefinierbaren Abständen auch ihren aktuellen Zustand in die Welt hinaus, was eine
Auswertung schwierig macht. Das Attribut hilft...

Gruß, Marc

[c2j2]

Sorry - wie hast Du das hinbekommen, dass die Fensterkontakte am CUL ankommen (und somit sofort registriert werden)? Habe grad einen Knoten im Hirn...

Ich habe einen MAXLAN cube und einen MAX CUL:

Code Auswählen Erweitern


define CUBE_max MAXLAN 192.168.2.47 15
attr CUBE_max alias MAXCube
attr CUBE_max icon cul_cul
attr CUBE_max room MAX

define CUL_max  CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105HDC4-if00-port0@38400 2234
attr CUL_max rfmode MAX
attr CUL_max room MAX


Und ich habe als Devices z.B.:

Code Auswählen Erweitern


define Fenster_wohnzimmer.Balkon MAX ShutterContact 0a4c4b
define Heizungsventil_wohnzimmer.Nord MAX HeatingThermostat 12d8d9
attr Fenster_.+ IODev CUL_max
attr Heizungsventil_.+ IODev CUBE_max


So, eigentlich würde ich erwarten, dass die Fenster-Events über den CUL kommen. Aber wenn ich die Fenster-Devices anschaue, sind die plötzlich "woanders", bei "IODev CUBE_max". Sobald ich sie (manuell) auf CUL_max setze (das klappt erst mal), sind sie ein paar Sekunden später wieder auf CUBE_max.

Wie hast Du das geschafft, CUBE und CUL parallel zu betreiben?