neueste Beta wirft Fehler beim Starten

Begonnen von willyk, 31 Dezember 2019, 10:05:09

Vorheriges Thema - Nächstes Thema

willyk

Hi,
habe gerade - wegen anderer Probleme - die neueste Beta installiert. Weisungsgemäss habe ich MaxCommon.pm wieder entfernt.

Bei Starten gibt es jetzt eine Fehlermeldung:
2019.12.31 09:55:35.359 2: Switched maxcl_eg rfmode to MAX
2019.12.31 09:55:35.959 2: Switched maxcl_ug rfmode to MAX
2019.12.31 09:55:35.960 1: a CUL_MAX device is already defined !
2019.12.31 09:55:35.961 1: define cm_ug CUL_MAX 123457: a CUL_MAX device is already defined !
2019.12.31 09:55:36.001 1: Including ./log/fhem.save
2019.12.31 09:55:36.229 1: configfile: a CUL_MAX device is already defined !
Please define cm_ug 5e049bb2-f33f-e3d6-4283-6a36987da9840e23 first


Ich vermute, dass es mit der Original-MaxCommon.pm zusammenhängt. Oder mache ich sonst was falsch?
Danke + Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Wzut

Nein das hat nichts mit der MaxCommon zu tun sondern die Fehlermeldung kommt daher das du in deiner .cfg zwei CUL_MAX Geräte stehen hast.
Das ist zwar mit der Standart 14_CUL_MAX möglich , macht aber wenn man es tut mehr Probleme als Lösungen.
Fakt ist : Wer versucht zwei unabhänige MAX Wolken (verschiedene IDs an CUL_MAX) auf einer FHEM Instanz zu betreiben wird auf die Dauer nicht glücklich.
Das liegt daran das beim Senden der Weg zwar schön vorgeben ist,  MAX IODev -> CUL_MAX , CUL_MAX IODev -> CUL
Beim Empfang weiss der oder die CULs aber nichts von diese Zuordnung und gehen immer über das Internal Clients und damit ist nicht sicher welches CUL_MAX Device angesprochen wird. Um dies zu umgehen gibt es jetzt nur noch maximal Eines pro FHEM Instanz.
Die Beta unterstützt aber mehr als einen CUL am einzigen CUL_MAX Device mit dem Attribut IOgrp
 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher