Die MAX Module heute und die Aussichten für 2020

Parador · 29 April 2020, 17:24:16

Danke nochmal für die Hilfestellungen, habe die beiden Dateien erfolgreich eingebunden!
Habe auch gesehen, dass die Hilfestellung schon im Beta-Thread ist - spitze!

Nun bin ich dabei mich mit dem VirtualShutterContact (VSC) auseinanderzusetzen. Dazu habe ich noch Fragen

ich habe ja schon Fensterkontakte, diese liefern in der Regel ein "auf/zu", bisher habe dann diesen Zustand kontrollieren lassen und ein Signal an den jeweiligen HT FakeShutter gesendet. Neu lege ich einen zusätzlichen VSC an an den ich dann das Signal senden lasse, anstelle direkt an den HT - richtig?
Ich habe gelesen, dass es wichtig (notwendig?) ist bei HT und VSC eine GroupID zu setzen, die zusammenpassen muß. Damit der VSC die zu steuernden HT kennt. Zusätzlich dem HT noch den VSC zuordnen, damit alles klappt.
Wenn ich das richtig verstanden habe, nun meine ergänzende Frage: Damit kann ich z.B. einen Raum mit einem HT und einem Fenster wunderbar steuern, auch wenn in einem Raum mehrere Fenster sind, senden die jeweils ein "auf" an den einen VSC des Raumes, oder? Ich habe nun aber zusätzlcih geplant, dass wenn z.B. die Haustür länger offensteht, das komplette EG auf "Fenster offen" geht, dazu sendet nun die Tür nach einer Wartezeit "auf" an wen? An alle relevanten VSC? Bin ich da auch richtig unterwegs?
Wenn nun aber ein anderes Fenster im EG aufgemacht und kurz darauf geschlossen wird, sendet es ein "zu" an den VSC, obwohl die Tür z.B. noch offen steht... Wie löse ich das richtig, oder habe ich da etwas falsch verstanden?

Wzut · 29 April 2020, 19:22:17

Zitat von: Parador am 29 April 2020, 17:24:16
Neu lege ich einen zusätzlichen VSC an an den ich dann das Signal senden lasse, anstelle direkt an den HT - richtig?

den Satz verstehe ich nicht so richtig. Ja du kannst einen vSC anlegen, nein dem sendest du nichts !
Du belegst im vSC das Attribut externalSensor und der vSC macht den Rest - kein DOIF, kein notify

ZitatIch habe gelesen, dass es wichtig (notwendig?) ist bei HT und VSC eine GroupID zu setzen,

Notwendig, die groupID ist der Raum in der Original ELV Cube Firmware. IMHO schenkt die Mehrheit der User der groupID zu wenig Beachtung.

ZitatZusätzlich dem HT noch den VSC zuordnen, damit alles klappt.

Das HT/WT associate vSC ist zwingend notwendig damit ein HT/WT überhaupt auf Nachrichten dieses vSC regagiert.

Zitatsenden die jeweils ein "auf" an den einen VSC des Raumes, oder?

nein die senden nicht an den vSC , siehe oben. Das vSC Device sieht den open/close Event des FKs und sendet in Abhängikeit des Attributs sendMode

ZitatWie löse ich das richtig

gute Frage , ich hatte bisher nie die Test Stellung mehr als ein FK an ein HT/WT. Eigentlich müssten die Dinger sich intern dafür eine Tabelle anlegen und dann wenn min noch einer offen den WindowOpen Mode behalten.

Parador · 30 April 2020, 08:04:58

ok, der Reihe nach..
Ich bin nach der der Beschreibung bei "neue Beta Versionen von 10_MAX und 14_CUL_MAX" gegangen...
und bin leider nicht bis zum Punkt: braucht kein Doif/Notify gekommen ;-(

In Deiner Anleitung liest es sich als seidie GroupID nun zwingend zu setzen, aktuell habe ich Sie auch nicht gesetzt.

Ich habe jetzt einen HT mit einem FK über einen vSC verbunden und die Erkennung Fenster auf/zu klappt! Danke

Wenn Du jetzt noch eine Idee zu meinem "komplettes EG runterfahren, wenn ein Fenster/Tür im EG länger als x Minuten offen ist" hinbekommst, wäre das spitze.
Aktuell löse ich das über Doif's mit wait, wenn ich aber im Moment alles richtig verstanden habe, fällt diese Option weg.... da keine Doif wie beim FSC mehr zum Einsatz kommen

Wzut · 30 April 2020, 08:43:01

a. wie ich schrieb : groupId ist leider ein Stiefkind für die User , tue dir den Gefallen und mach es gleich sauber , d.h. setze sie.
b. welchen sendMode benutzt du z.Z. ?
c. nein dein verzögertes DOIF ist nicht raus , naürlich kannst du es weiter nutzen, nur für simple 1:1 Verbindungen werden sie halt im Gegensatz zum fakeSC halt nicht unbedingt gebraucht, da externalSensor dem User die Arbeit abnimmt - wenn er denn möchte.

Parador · 30 April 2020, 10:03:52

a. Ok, werde die GroupID mal pro Raum vergeben, ist ja auch schnell gemacht!
b. da primär ein FK zu einem HT habe ich es aktuell bei Broadcast belassen
c. Von der Reihenfolge was ist denn über/untergeordnet.... vSC oder FSC? und was ist wenn hier unterschiedliche Dinge ankommen?

noch eine andere Frage zu den Peers:
Bei mir finden sich in bei dem einen umgestellten HT folgende Einträge:

Code Auswählen

peerIDs: 000000,222222
peerList: Broadcast,MAX_222222
peers: 010201

010201 ist der vSC den ich angelegt habe,
000000 ist Broadcast, verstehe ich auch
222222 bzw. MAX_222222 ist der FSC... konnte ich nur der fhem.cfg entnehmen

könnte man dies vielleicht noch mit sprechenden Namen hinterlegen? Also z.B. den Device Namen dazuschreiben? Oder ist das dann zuviel Information und überflüssig?

Wzut · 30 April 2020, 12:58:43

peerIDs & peerList sind die gleiche Liste : mit wem hat das Gerät gesprochen -> einmal die Hex Adresse und einmal der FHEM Device Name

Das 222222 die fakeSC Adresse ist war schon immer so, nur halt unsichtbar für den User. Jetzt sieht man sie -> Attribut fakeSCaddr am CULMAX Device und man darf sie sogar ändern

peers ist eine Liste die sich auf und abbaut durch absetzen des associate/deassoicate Kommandos -> Ausnahme die virtuellen Geräte SC und Thermostat,
da hier kein set associate ausgeführt wird muss der User die Liste als Attribut selber pflegen. Wie ich in der Doku bereits schrieb kann man die nicht vom Gerät zurücklesen, also gut merken, aufschreiben oder mittels saveConfig von Hand sichern oder Attribut autoSaveConfig setzen und automatisch bei jeder Änderung sichern.

Und die Liste willst du nun nochmal als sprechende Namen haben ?
wenn ja : werd ich so schnell nicht tun, Namen sind Schall & Rauch und können sich mittels rename ändern, die HEX Adressen dagegen sind in Stein gemeißelt.

Parador · 30 April 2020, 13:58:20

Alles klar, Danke für die Ausführungen und die viele Mühe!! Toll das Du dieses Modul so gut überarbeitest!
Werde jetzt erstmal die Umstellung bei mir Stück für Stück vornehmen.

Wzut · 30 April 2020, 19:32:52

Zitat von: hyper2910 am 29 April 2020, 13:27:04
Kannst du schon sagen, wann die Module ins normale update kommen???

ja stimmt , das negativ Echo war bisher bescheiden und die Heizperiode geht auch langsam zu Ende.
Ganz zu schweigen von der Tatsache das ich nun schon seit Tagen an der Beta von der Beta schraube .....
machen wir es wie im Kinderlied "Alles neu macht der Mai"

Zitatalles freut sich der Zeit, die verschönt erneut.
Widerschein der Schöpfung blüht uns erneuend im Gemüt.
Alles neu, frisch und frei macht der holde Mai

Parador · 30 April 2020, 20:08:40

Bei der Umstellung hat sich noch eine Frage ergeben:
Was mache ich bei mehreren Fenstern? Im vSC hinterlege ich ja als external Sensor einen FK, kann ich auch mehrere hinterlegen? Oder wie mache ich das richtig?

Wzut · 01 Mai 2020, 06:32:16

Der Sinn des virtuellenShutterContacts ist u.A. das man soviele davon anlegen kann wie einem Adressen einfallen. Der fakeSC ist auf einen pro Installation beschränkt.
D.h. du legest dir für jeden echten FK einen virtuellen Bruder an

Parador · 01 Mai 2020, 08:14:16

Ah, ok! Das würde ich als Ergänzung noch in die Anleitung packen.

Aber den FSC gabs nur einmal? Hm, ich hatte den Eindruck dass ich da mehr hatte, einen pro HT... aber das hätte ich mir wohl mal in der fhem.cfg ansehen müssen. Hat einigermaßen gut geklappt.

Wzut · 01 Mai 2020, 08:42:03

wenn mehr als ein fakeSC möglich wäre :
a. gäbe es die Probleme der User nicht
b. hätte ich mir die Arbeit sparen können ein virtuelles Device zu erfinden.

Parador · 01 Mai 2020, 09:03:59

ok verstehe, komisch hat bei mir geklappt.

Jetzt ist ein Problem aufgetaucht: Ich habe einen vSC angelegt und habe die falsche MAX-ID (laut meiner Logik) erwischt.
Bin daraufhin nochmal in die Device-Def und habe Sie geändert.
Dann wollte ich am HT den vSC assoziieren... Aber jetzt taucht er zwei Mal auf.
Wenn ich das Device lösche, verschwindet einer, der andere ist immer noch da...

Wzut · 01 Mai 2020, 12:29:52

FHEM Grundlagen : Readings von Geräten kann der User selbst nach Lust & Laune selbst verbiegen, das Zauberwort nennt sich setreading
Ich kann im Modul nicht alles vorsehen was der User so macht, daher auch keine Änderung von Readings am Gerät A wenn B von Hand angepasst wird.

Parador · 01 Mai 2020, 13:31:04

Hallo Wzut,

danke für den Hinweis, allerdings wüsste ich nicht wo ich ein Reading ändern sollte.
Vermutlich habe ich mich falsch ausgedrückt. Ich habe einen vSC (Name AAA) mit falscher ID (020201) angelegt. Dieser spukt nun noch als Geist herum.
Wenn ich in den vSC (AAA) gehe, steht inzwischen die richtige 6-Stellige MaxID (020401) darin, das geht ja über die DEF. Auch im zugehörigen HT steht die richtige.
Wenn ich nun aber versuche einen weiteren vSC (Name BBB) anzulegen diesmal ist die MaxID (020201) laut meiner Logic die richtige, sagt mit FHEM diese sei bereits vergeben und verweist auf den vSC (AAA)...
Auch wenn ich bei einem HT in das DropDown zum Associate gehe taucht der eigentlich gelöschte vSC (AAA) zusätzlich oder wenn wieder korrekt angelegt doppelt auf.
Mir ist im Moment also unklar, was ich korrigieren muss, damit der "Geist" verschwindet.

Ergänzung: Ich habe gerade mal einen Neustart gemacht und jetzt scheint der Geist verschwunden zu sein!