Ein paar Anregungen aus einem anderen Chat (für MAX Entwicklung)

Begonnen von LS, 21 März 2021, 17:04:20

Vorheriges Thema - Nächstes Thema

LS

Das hier ist eher was für MAX Entwickler:

Ich hatte mich mal wieder über FHEM un MAX geeärgert
und mit jemandem gesprochen, der sich sein eigenes Home-Automation System gebaut hat.
Evtl. kann kann jemand mit Ahnung aus diesem Chat-Fragment etwas positives für die FHEM Entwicklung ableiten:

...
fhem könnte einfach Uhren grundsätzlich nur stellen wenn es >30min credits auf dem Konto hat,
dem die gleiche Priorität zu geben wie durch den User getriggerten Requests ist einfach nur dumm.

An einer anderen Stelle haben sie auch das Problem nicht verstanden:
Diese timeinformation-messages sind nur deshalb so teuer, weil sie mit Preamble geschickt werden.
Wenn sie als Antwort auf einen timeinformation-request eines Thermostats geschickt werden, ist das aber eh wach, und die Preamble ist vollkommen überflüssig.

Warum sie timeinformation nicht einfach broadcasten, sondern an jedes gerät einzeln unicasten, ist mir aber immer noch schleierhaft - klar, so bekommt man Acknowledgements, die man anders nicht hätte, aber wenn mal einen tag einem Device die Uhr zu stellen schief geht ist das ja nicht dramatisch.

Das Zeug ist cleverer als ich dachte - group multicast an "ungrouped" wirkt tatsächlich als Broadcast,
inkl. der Geräte die eine andere gruppe haben, also man kann mit einer einzigen ~150-credit-message alle Uhren in Reichweite stellen, die einem vertrauen.

header(source=cube, dest=000000, flags=04, groupid=00) timeinformation(time=...) funktioniert

U.a. kann man Thermostate gezielt nach der ist-temperatur und ventilstellung etc. fragen, und sogar die konfiguration zurücklesen

header(source=cube, dest=<device>, flags=08, groupid=00) thermostatstate()

Wenn man mal aufmerksam ein paar Messages angeschaut hätte, insbesondere wie Thermostate die Uhrzeit vom Cube anfragen, und wie das relativ zu einem "setze Uhrzeit" aussieht, dann stellt man fest, dass man genau dasselbe mit vielen anderen Messages auch andersrum machen und das device fragen kann.

Das mit den query messages hatten sie offenbar auch nicht verstanden, obwohl es eigentlich doch recht auffällig ist, wenn man dieses "query timeinformation"-paket sieht, was die Thermostate schicken.

Wer auch immer das für FHEM gebaut hat, hat offenbar das komplette Konzept von Broadcasts ignoriert - FHEM benutzt die nie, obwohl die vieles deutlich effizienter machen.

Wenn man so nen Sack voll Schedules senden will, weckt man ALLE Geräte auf einmal, mit einer Preamble, sagt ihnen, dass sie die nächsten 5 Sekunden wach bleiben sollen, und haut die Schedules alle am Stück über den Funk - kostet so um die 300 Credits pro Device.

Grüße LS

PS: Und könnte evtl. mal jemand die Forum Software fixen, dass das Posten eines Kommentars auch mit Firefox tut - oder zumindest groß warnen wenn man es im Firefox versucht !!!!

Wzut

THX, ich fang mall "hinten" an : Firefox ist keine Problem ich verwende ihn selbst, man muss halt die richtigen Tags setzen ist aber völlig unabhängig vom Browser und gehört hier nicht her.

Was den Text betrifft :
Ja da stecken einige Infos drin dir mir persönlich neu sind, das eine oder andere habe ich inzwischen auch schon heraus bekommen.
Ich will mich nicht entschuldigen, ich habe die MAX Module geerbt ohne wirklich Ahnung davon zu haben und musste mir vieles komplett sebst erarbeiten.
Ich bin mir sicher hätten diese Information vor langer Zeit dem MAX Modul Autor M. Gehre zur Verfügung gestanden, hätte er reagiert und wir wären heute vermutlich ein gutes Stück weiter und ich hätte mir einige Stunden/Tage try & error ersparen können.
Da ich den von dir zitierten schlauen Mensch nicht genauer befragen kann muß ich jetzt halt schauen was ich davon in die Realität umsetzen kann. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: LS am 21 März 2021, 17:04:20
U.a. kann man Thermostate gezielt nach der ist-temperatur und ventilstellung etc. fragen, und sogar die konfiguration zurücklesen
header(source=cube, dest=<device>, flags=08, groupid=00) thermostatstate()
Beim ersten Punkt ist Temperatur & Ventilstellung war ich gestern Abend erfolgreich obwohl ich noch unsicher bin ob ich es so elegant einfach gemacht habe wie beschrieben.
Anyway, der zweite Punkt Konfig rücklesen wäre natürlich extrem schön aber ich fürchte mein heutiges Wissen reicht dafür nicht aus.
Vllt fehlt mir auch nur noch das entscheidene Puzzelteil, daher würde ich denjenigen gerne mal selbst ein zwei Fragen stellen wenn es irgendwie möglich wäre da einen direkten Kontakt herzustellen.
Ich nehm natürlich auch jede andere Hilfe von wem auch immer gerne an.
Es ist halt schade das von den ganzen Jungs mit richtig Ahnung zum Thema Funk & Protokolle niemand zur MAX Fraktion gehört, denn ich könnte wetten das das was da heute seit Jahren unverändert in der CUL FW schlummert auch noch nicht der Weisheit letzer Schluss ist.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Falls hier noch jemand mitliest :
Das Wort Dammbruch ist ein großes Wort, aber mein Staudamm hat inzwischen auf der Talseite einen großen nassen Fleck und an einzelen Stellen sickert Wasser aus kleinen Rissen :)
D.h. ist wohl nur eine Frage der Zeit bis der Rest ganz nachgibt.
z.Z. kann ich die Zeit an alle schicken, das Wochenprofil zurücklesen und Teile der Config.
Die entsprechenden Antworten kommen schon mal von den Geräten (HT/WT) allerdings fehlen nun noch die entsprechenden Unterprogramme um diese Antworten richtig auszuwerten.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Johnnyflash

Hallo,
das freut mich riesig und erweitert in meinen Augen das Potential des Systems drastisch. Ich hoffe, dass sich besagte Person noch persönlich dazu äußert, offenbar schlummert im vermeindlich "dummen" Max-System deutlich mehr, als bisher angenommen.

Wzut

also das flag -> 08 hat sich inzwischen als wahre Dambuster Rollbombe herausgestellt :)
Damit war es nun möglich erfolgreich die Temperatur Configs und Wochenprogramme von HTs und WTs auszulesen.
Zum reinen Luxusglück fehlen mir eigentlich noch noch zwei Dinge :
a. auslesen der aktuellen GroupId , und
b. auslesen der mit diesem Gerät assozierten anderen MAX Geräten.
Keine Ahnung ob das überhaupt irgendwie möglich ist, mit meinen bescheidenen Mitteln bin ich auf jeden Fall ohne Erfolg durch.
Wäre halt schön wenn der TE  LS sich nochmal melden würde um abzukären ob es überhaupt Sinn macht da noch weitere Energie zu investieren.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

thburkhart

Zitat von: LS am 21 März 2021, 17:04:20
Das hier ist eher was für MAX Entwickler:

Ich hatte mich mal wieder über FHEM un MAX geeärgert
und mit jemandem gesprochen, der sich sein eigenes Home-Automation System gebaut hat.
Evtl. kann kann jemand mit Ahnung aus diesem Chat-Fragment etwas positives für die FHEM Entwicklung ableiten:

auch ich würde es begrüßen, wenn dieses "Fremdwissen" der MAX-Weiterentwicklung konkreter zufließen könnte

bg
Thomas
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200