Die MAX Module heute und die Aussichten für 2020

Begonnen von Wzut, 22 Dezember 2019, 13:46:18

Vorheriges Thema - Nächstes Thema

jonien

Hallo,
ich finde es toll, das es neue Entwicklungen für die MAX Module gibt. Viele nützliche Neuerungen.
Ich habe vor ca. 2 Wochen auf einem Zweitsystem (mit MAXLAN) die damals akt. Beta Versionen von 10_MAX.pm und 14_CUL_MAX.pm integriert. Alle MAX Geräte (Thermostate Fensterkontakte Taster) wurden erkannt, die geänderte Ansicht in Fhem und neue Attr. waren sichtbar. Und es gab das MAXtemplate in der Auswahlliste. So weit richtig gut...
Mein Ziel war, einen virtuellen Fensterkontakt (ähnl.wie bei HM) anzulegen (habe ich bisher nur mit einer "Krücke" gelöst). Das hat dann nicht funktioniert: nach Eingabe der GrID kam die Fehlermeldung IO Gerät nicht verfügbar (oä), (im Beta-Status noch nicht möglich?).
Deshalb habe ich per Update die Original Module wieder hergestellt, so weit so gut.
Nun wollte ich mit den Beta Modulen (akt. Stand) einen neuen Versuch starten...   Alles wie zuvor, aber ich kann die MAXtemplates nirgendwo finden in der Geräteansicht, bzw. aktivieren.... (Im Ordner \FHEM\lib\AttrTemplate liegt  ein MAX.template vom 16.3 195kb). Irgendwie stehe ich auf dem Schlauch, hat jemand einen Tipp...?

Liebe Grüße Jörg

Wzut

#76
Die Original Module unterstützen nicht den Download von Templates, d.h. was im Template steht musst du dann jeweils einzeln für jedes Device ausführen.
Versuch es nochmal mit der letzten Beta, wichtig ist das du zuvor ein update MaxCommon machst.
Deine Fehlermeldung sagt mir in der Form nichts, bitte wenn Probleme auftauchen sollten die "echten" Meldungen posten, ich kann mir nicht vorstellen das wir das nicht hin bekommen.

Edit : sorry mein Fehler. Im max.template ist der falsche Filter daher wird keine Auswahl angezeigt. Ich checke die neue Version ein (FHEM neu starten)
bzw. hänge die aktuelle Version hier an.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jonien


jonien

... die MAXtemplates können jetzt ausgewählt werden.  :D  Hat sich ja einiges getan...

Beim set attrtemplate kommt diese Fehlermeldung:
"Unknown template_entry_name speech_recognition_type_thermostate"

Wzut

Die Fehlermeldung hatte ich auch und musste mich dann belehren lassen das mein FHEm nicht aktuell sei ....
(als Schnellhilfe kannst aber auch den set Befehl in jedem Template auskommentieren wobei IMHO trotz der Meldung alles andere umgesetzt wird)   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jonien

ok :)

Gibt es für den ShutterContact auch ein template?  Wird aktuell noch nicht angezeigt.

Zu meinen Versuchen mit dem virtuellemFensterkontakt, sollte das schon möglich sein?

Wzut

Für FKs gibt es kein Template , a. weil mir bisher für die nicht Sinnvolles eingefallen ist und b. hatte ich mir hier https://forum.fhem.de/index.php/topic,109034.0.html mehr versprochen.

Was sollte möglich sein ? IMHO ist der virtuelleShutterContact fertig und macht was er soll.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jonien

...mit dem virtuellemFK werde ich nochmal testen.

Für die FK habe ich in der alten Conf. es wie folgt dargestellt. Ist aber immer viel Handarbeit...:

Wzut

etwas weniger wird die Handarbeit wenn du statt die ganzen Attribute von Device zu Device kopierst , die am Stück in ein eigenes Template packst.
OK, das brachte bisher nichts da 10_MAX keine Templates unterstütze, aber jetzt ist das ein möglicher Weg.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jonien

...das ist ein guter Weg!

Beim virtFK mache ich wahrscheinlich einen Denkfehler, an dem ich immer wieder scheitere. So habe ich es versucht:

virtFK:
define Fenster_Bad_v MAX virtualShutterContact 345678
set virtFK open             > Unknown argument open, choose one of deviceRename groupid open close

...device gelöscht, dann...

virtFK:
define Fenster_Bad_v MAX virtualShutterContact 345678
set groupid 2
   
Dazugehöriges Thermostat: (groupid=2)
set  HzgTh_Bad   associate   Fenster_Bad_v

virtFK:
set virtFK open           > Fenster_Bad_v, invalid IODev

Wzut

a. lists im Code Tags sind immer besser als Screenshots
b. schreibst du weiter oben das du 10_MAX und 14_CUL_MAX im Einsatz hast, dein IO trägt den Namen maxlan.
Ist der nur unglücklich gewählt oder steckt hinter maxlan wirklich 00_MAXLAN und nicht 14_CUL_MAX ?
Dem Cube mit der Original Firmware kann man keine virtuellen Geräte beibringen !
Das würde die auch die Fehlermeldungen mit dem invalid IO erklären.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

LostInSpace

Hallo würde mich noch als lernfähigen Anfänger beschreiben und bin froh das es im MAX Bereich jetzt eine Menge mehr an Möglichkeiten gibt. Ich nutze fhem auf einem raspi 2b mit einem max-cul. Betreibe parallel bei meinem Bruder, der eine Etage unter mir wohnt, auch fhem auf einem raspi 3 und einem max-cul. Ist nicht gerade immer einfach Des Weiteren scheint es in der Nachbarschaft noch weitere MAX Nutzer zu geben. Da immer mal wieder neue unbekannte Geräte auftauchen.

Ich habe jetzt bei mir und meinem Bruder die Beta Module installiert und bekomme beim starten folgende Fehlermeldung:

2020.03.18 20:26:08 1: PERL WARNING: Use of uninitialized value $_ in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 156.

Ist das ein Fehler im Code?

Wzut

Naja Fehler nicht direkt , es ist wie der Name schon sagt eine Warnung.
In der besagten Zeile 156 geht es um das Attribut IOGrp daher die Frage : Was hast du da eingetagen und hast du überhaupt eine Gruppe ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: LostInSpace am 18 März 2020, 20:39:47
Da immer mal wieder neue unbekannte Geräte auftauchen.
Das lässt sich trotz check leider nicht vermeiden es gibt immer wieder mal zerstörte Telegramme die dann doch irgendwie passen.
Daher mein Tipp : autocreate auf disable und nur einschalten wenn wirkliche neue Geräte ins System sollen.

Ich konnte auch die Zeile 156 nachvollziehen , war ein copy&paste Fehler wenn IOgrp nicht verwendet wird.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

LostInSpace

#89
Danke bzgl. Hinweis autocreate. Sind erst einmal disabled.

Also ich habe mit set groupid und attr. group ein wenig herum experimentiert. War aber noch nicht so wirklich zielführend. Und jetzt bekomme ich die Einstellung allerdings auch nicht mehr gelöscht.

Versuche allerdings gerade bei meinem Bruder 2 neue WTs einzubinden. Werden per autocreate auch erkannt. Versuche gerade weekproofile zu übermitteln.  Die Befehle werden leider nach und nach aus der Sendeliste gelöscht. Wegen fehlendem ACC vom WT.

Irgendwo ist da aktuell der Wurm drin.. Mal schauen.