AskSin++ Library

[Tom Major]

Deswegen auch das Angebot an LuBeDa, den FHEM Perl code HMConfig_SenTHPL.pm für das neue Unisensor Demo anzupassen falls er das dann in FHEM testen kann...

[Gruenebe]

Hallo zusammen,
mit Interesse verfolge ich diese Entwicklung. Den einen oder anderen Sensor habe ich schon testweise nachgebaut, ohne wirklich die Funktionsweise des Sketches zu verstehen.

Welcher Aufwand ist es, einen HM-MOD-EM-8 nachzubilden?

Am Original stört mich, dass er nach dem Einschalten nicht sofort den aktuellen Zustand liefert. Ich verwende diesen, um Reedkontakte (Fenster) abzufragen, muss nach einem Reboot der CCU aber erst jedes Fenster auf und wieder zu machen, damit der Sensor den richtigen Zustand liefert. Ich hatte dies bereits vor längerer Zeit bei EQ3  angemerkt, aber dort gibt es ja kaum noch Änderungen an der original FW. Vom Programmieraufwand kann dies m.E. nicht so viel sein, um beim Init erstmal alle Ports der Reihe nach abzufragen...

Es wäre daher super von Euch, wenn jemand für diesen Sensor einen Sketch entwickeln könnte.

VG

[Tom Major]

Wie hoch der Aufwand für eine direkte Nachbildung eines HM-MOD-EM-8 ist kann ich nicht sagen, dazu stecke ich zu wenig in den diversen HM Listen, Modi, channels usw. drin.
Das UniSensor Beispiel lässt sich aber leicht so anpassen dass IO Bits der Reedkontakte anstatt Sensorwerte übertragen werden, entweder als 1 Byte pro Eingang oder 1 Bit pro Eingang, das xml file lässt sich für beide Varianten anpassen. Das könnte man natürlich auch bei Einschalten des Sensors für alle IOs übertragen.

Am Original stört mich, dass er nach dem Einschalten nicht sofort den aktuellen Zustand liefert. Ich verwende diesen, um Reedkontakte (Fenster) abzufragen, muss nach einem Reboot der CCU aber erst jedes Fenster auf und wieder zu machen, damit der Sensor den richtigen Zustand liefert. Ich hatte dies bereits vor längerer Zeit bei EQ3  angemerkt, aber dort gibt es ja kaum noch Änderungen an der original FW. Vom Programmieraufwand kann dies m.E. nicht so viel sein, um beim Init erstmal alle Ports der Reihe nach abzufragen...

Dieser Punkt ist mir unklar. Das würde voraussetzen das der Sensor ein reboot der CCU mitbekommt und dann den Status senden kann. Ein Sensor ist ja normalerweise im power down oder power save Modus wo er keinen Empfang hat. Keine Ahnung ob es eine Lösung gibt, trotzdem das reboot der CCU mitzubekommen, ist eventuell schwierig.

[Gruenebe]

Stimmt, so hatte ich das noch gar nicht gesehen. Der Sensor kommuniziert nur mit der CCU, wenn sich sein Zustand ändert oder bei Lowbat. Von einem Reboot bekommt er also nichts mit, da die Kommunikation nur in eine Richtung geht. Es müsste eine Möglichkeit geben, dass die CCU den Zustand aktiv abfragen kann, also einen Befehl dafür an den Sensor schickt und dieser darauf die aktuellen Zustände überträgt.

[Tom Major]

Das Problem dabei ist dass das Modul im power-down Modus ist. Verbaut ist ein STM8L151 und von ELV beworben werden 3 uA Standby. Das ist dann der  Low-power wait mode des STM8, eine Änderung an seinen Ports weckt ihn auf. Ohne diese Änderung wird er halt den "Abfrage-Befehl" der CCU nicht empfangen können da im sleep.

[Klaus0815]

Der Sensor kommuniziert nur mit der CCU, wenn sich sein Zustand ändert oder bei Lowbat. Von einem Reboot bekommt er also nichts mit, da die Kommunikation nur in eine Richtung geht. Es müsste eine Möglichkeit geben, dass die CCU den Zustand aktiv abfragen kann, also einen Befehl dafür an den Sensor schickt und dieser darauf die aktuellen Zustände überträgt.

was wäre, wenn Du zusätzlich den Zustand  z.B. alle 6 / 12 / 24h einfach neu überträgst? So oft startest Du ja im Normalfall die CCU / FHEM nicht neu?

[Tom Major]

oder ein "Advanced" AskSin++ HM-MOD-EM-8, und ich glaube in diese Richtung ging ja auch die ursprüngliche Frage, welches
a) beim power-on alle IO Statusinfos sendet und/oder
b) einen extra Taster hat, welcher bei Betätigung diese Statusinfos überträgt.
Dann könnte man nach CCU reboot ein power-reset am HM-MOD-EM-8 machen oder eben den Taster drücken - das spart dann den Gang zu jedem Fenster 

Wieso speichert die CCU eigentlich nicht den letzten Status aller Reedkontakte bei diesem Modul?

[LuBeDa]

Angebot an LuBeDa

Gerne!!! ,
macht aber erst Sinn wenn meine Bauteile aus China angekommen sind. Bis dahin werde ich mal einen Blick in die XML und Perl-Module werfen.

Richtig cool wäre ein FHEM Modul bei dem man die XML importiert und die Readings werden durch die Einstellungen in der XML aufgebaut.

Habe aber keine Ahnung wie utopisch diese Idee ist.

Ludger

[Gruenebe]

oder ein "Advanced" AskSin++ HM-MOD-EM-8, und ich glaube in diese Richtung ging ja auch die ursprüngliche Frage, welches
a) beim power-on alle IO Statusinfos sendet und/oder
b) einen extra Taster hat, welcher bei Betätigung diese Statusinfos überträgt.
Dann könnte man nach CCU reboot ein power-reset am HM-MOD-EM-8 machen oder eben den Taster drücken - das spart dann den Gang zu jedem Fenster 

Helfen würde ja auch schon, wenn bei jeder Änderung der Zustand aller 8 Ports (1 Byte) übertragen wird und nicht nur das geänderte Bit, was es ja zu sein scheint. 1 Fenster nach dem Reboot öffnen oder schliessen ist nicht so aufwändig, als 8.

[Tom Major]

Helfen würde ja auch schon, wenn bei jeder Änderung der Zustand aller 8 Ports (1 Byte) übertragen wird und nicht nur das geänderte Bit, was es ja zu sein scheint. 1 Fenster nach dem Reboot öffnen oder schliessen ist nicht so aufwändig, als 8.

Genau, wäre eine 3. Möglichkeit, finde ich auch gut.

Warum die CCU nicht den letzten Status speichert habe ich das hier gefunden im HM Forum:

Das der Status der Sensoren nicht stimmt bzw. nicht abgefragt wird ist eine bekannte hier oft diskutierte Eigenschaft des Systems. Daran wird sich nichts ändern. Das HM Konzept bei Batteriebetrieb ist so. An der Stelle muss man andere Hardware einsetzen, wenn es für die konkrete Anwendung so wichtig ist.
Herbert_Testmann

Also ein weites Feld für eigene HW und Firmware Konzepte, die man mit der Lib hier realisieren kann 

[jp112sdl]

Das der Status der Sensoren nicht stimmt bzw. nicht abgefragt wird ist eine bekannte hier oft diskutierte Eigenschaft des Systems.

Warum die CCU nicht den letzten Status speichert habe ich das hier gefunden im HM Forum:Also ein weites Feld für eigene HW und Firmware Konzepte, die man mit der Lib hier realisieren kann 

Das ist wohl der Kompromiss, den man eingehen muss, wenn man die größtmögliche Batterielebensdauer herausholen will und die Geräte nicht mal per Burst geweckt werden können.
Jedoch nicht nur bezüglich der Batterielebensdauer hätte ich da bedenken.
Wenn nach einem Reboot der CCU alle Batterie-Sensoren (betrifft ja z.B. auch die Tür-/Fensterkontakte, Drehgriffkontakte) nacheinander geweckt werden müssten, um den Status abzufragen, wäre man ganz schnell bei einer Auslastung des DutyCycle.
Der liegt bei mir nach einem Reboot so schon bei ~40...60% (Normalbetrieb ~5%). Wenn ich dann einen Batterieaktor innerhalb der ersten Stunde 5 oder 6x schalte, bin ich bei 100% angekommen.

Aber abgesehen davon - wann startet man die CCU neu?
Entweder bei einem Firmware-Update. Da macht man es bewusst und man kann sich drauf einstellen, ggf. "wichtige" Kontakte anschließend einmal zu schließen/öffnen.
Oder nach einem Stromausfall, was (hoffentlich) nicht mehr als 1x pro Jahr (wenn überhaupt) vor kommt.
Ich denke, das ist vertretbar.

[Gruenebe]

Das ist wohl der Kompromiss, den man eingehen muss, wenn man die größtmögliche Batterielebensdauer herausholen will und die Geräte nicht mal per Burst geweckt werden können.
Jedoch nicht nur bezüglich der Batterielebensdauer hätte ich da bedenken.

Batterielebensdauer spielt in meinem Fall keine Rolle, da die Readkontakte eh alle an eine zentrale Stelle gehen, wo ein Netzteil die Sensoren versorgt.

Wenn nach einem Reboot der CCU alle Batterie-Sensoren (betrifft ja z.B. auch die Tür-/Fensterkontakte, Drehgriffkontakte) nacheinander geweckt werden müssten, um den Status abzufragen, wäre man ganz schnell bei einer Auslastung des DutyCycle.
Der liegt bei mir nach einem Reboot so schon bei ~40...60% (Normalbetrieb ~5%). Wenn ich dann einen Batterieaktor innerhalb der ersten Stunde 5 oder 6x schalte, bin ich bei 100% angekommen.

Wo ist aber der Unterschied, ob ich nach einem Reboot nacheinander an jedes Fenster gehe und dort den Status ändern muß, damit der richtige Zustand erkannt wird. Da wird bei jedem einzelnen Fenster eine erneutes Senden erzwungen (für einen Sensor also 8x) gegenüber einer einzigen Abfrage bei der gleich alle 8 Zustände einmal übertragen werden.

Aber abgesehen davon - wann startet man die CCU neu?
Entweder bei einem Firmware-Update. Da macht man es bewusst und man kann sich drauf einstellen, ggf. "wichtige" Kontakte anschließend einmal zu schließen/öffnen.
Oder nach einem Stromausfall, was (hoffentlich) nicht mehr als 1x pro Jahr (wenn überhaupt) vor kommt.
Ich denke, das ist vertretbar.

Das ist nicht die Frage und wohl von jeder individuellen Situation abhängig. Wenn ich damit z.B die Fenster in einem Wochenendhaus überwachen will, geht das nicht, da ich nach jedem Stromausfall, auch wenn er geplant ist, hinfahren müsste, um den Sensor neu zu initialisieren.

Warum machen wir SmartHome?
In erster Linie um uns das Leben zu vereinfachen und sicherer zu machen.

Ich habe keine originalen Tür/Fensterkontakte, aber aus Deiner Bemerkung oben schliesse ich, dass die das gleiche Verhalten haben. Also auch ,,manuell aufgeweckt" werden müssen.
Bei meinen Fensterkontakten ist es noch so, dass diese bei Zustand offen und Regen die Rolläden runter fahren sollen - typisches SmartHome Szenario. Fällt aber vor einem Starkregen der Strom aus, habe ich u.U. die Bude voll Wasser. Das will man ja eigentlich vermeiden.

[Gruenebe]

was wäre, wenn Du zusätzlich den Zustand  z.B. alle 6 / 12 / 24h einfach neu überträgst? So oft startest Du ja im Normalfall die CCU / FHEM nicht neu?

Ich kann den Sensor ja leider nicht aus einem Programm heraus zwingen, den aktuellen Zustand der Ports zu übertragen. Nur eine Portänderung überträgt den neuen Zustand an die CCU.

[jp112sdl]

Batterielebensdauer spielt in meinem Fall keine Rolle, da die Readkontakte eh alle an eine zentrale Stelle gehen, wo ein Netzteil die Sensoren versorgt.

Ok, da hätte man einen "Netzteil"-Modus einbauen können.
Dann müsste der HM-MOD auch noch so intelligent sein, dass er bei Nichterreichbarkeit seiner angelernten Zentrale, alle x Minuten seinen (kompletten) Status erneut überträgt.
Aber da wir von eQ-3 nichts neues mehr im klassischen HM-Sektor erwarten brauchen, muss wohl wirklich eine Custom-Lösung her

Warum machen wir SmartHome?
In erster Linie um uns das Leben zu vereinfachen und sicherer zu machen.

Ich habe keine originalen Tür/Fensterkontakte, aber aus Deiner Bemerkung oben schliesse ich, dass die das gleiche Verhalten haben. Also auch ,,manuell aufgeweckt" werden müssen.
Bei meinen Fensterkontakten ist es noch so, dass diese bei Zustand offen und Regen die Rolläden runter fahren sollen - typisches SmartHome Szenario. Fällt aber vor einem Starkregen der Strom aus, habe ich u.U. die Bude voll Wasser. Das will man ja eigentlich vermeiden.

Dein Szenario ist denkbar, aber sehr unwahrscheinlich.
Dann müsste der Strom vor dem Starkregen aber rechtzeitig wieder zurück sein, damit dein Rollladen ja auch fahren kann.
Um Stromausfälle (rechnerisch bis zu 1 Tag) zu puffern, nutze ich am RaspberryMatic eine Goobay Powerbank mit 20.000mAh.
Könnte man sicher auch in die CCU-Stromversorgung einschleifen.

Aber gut - vielleicht erfüllt HomeMatic wirklich nicht deine Ansprüche. Es gibt ja auch noch zahlreiche weitere Anbieter.
Ich habe mich auch schon desöfteren grün und blau geärgert über HM.

Ja, bei den originalen TFK (HM-Sec-SCO) ist es genau so.

[Gruenebe]

Aber da wir von eQ-3 nichts neues mehr im klassischen HM-Sektor erwarten brauchen, muss wohl wirklich eine Custom-Lösung her

Genau das war ja mein ursprünglicher Ansatz, bevor die Diskussion dann etwas OT wurde.

Leider muß ich, was die Programmierung angeht, im Bereich C(++) und OO-Programmierung passen.
Ich kann die Beispiele zwar in der Arduino IDE nachbauen und auch auf den Mini Pro bringen, aber verstehe nicht, was bei der BidCos Kommunikation abgeht.

Meine Stärken liegen eher im Bereich der Hardware.

Da meine SmartHome Anfänge schon etwas zurückliegen, hatte ich anfänglich auf eine CC2 Lösung von Conrad gesetzt mit den Erweiterungen von Andre Helbig (CC2Net).
Das Porgrammierniveau dort, ist etwas, wo ich noch mitkomme.

Problematisch war jedoch, dass die gesamte Hauskommunikation auf einem I2C bzw. CAN Bus basierte.
Kabeltechnisch weniger das Problem, da ich als ich mein Haus vor mehr als 10 Jahren gebaut habe, sehr viel CAT5 Kabel verlegt habe. Daher auch die Reedkontakte von den Fenstern.
Über lange Strecken war die Kommunikation darüber aber nicht sehr stabil, so dass ich dann vor etwa 2 Jahren auf Homematic umgestellt habe.

Meine Idee war nun, man könnte z.B. die zahlreichen I2C Erweiterungen von Andre https://www.cctools.eu/artikelindex.php/I2C-Bus mit dem Arduino verheiraten.
Vorteil von Andre`s Lösungen aus meiner Sicht sind die zahlreichen Hutschienenvarianten, wo man in das Gehäuse locker noch einen Arduino unterbringen könnte.
Man bräuchte nur die Spannung intern abgreifen und die I2C Ports des Arduino mit den Lötpunkten (Steckern) auf der Platine verbinden.

So könnte man z.B. mit der Max7311 Erweiterung ein 16 Kanal Eingangs- oder Ausgangsmodul bauen oder auch gemischt 8 Port Eingang und 8 Port Ausgang,
wie man es sonst nur von HM Wired kennt. Die Ansteuerung eines MAX7311 per I2C im Arduino ist nicht das Problem, das habe ich auch schon hinbekommen.
Ist letztendlich auch nichts anderes, als einen I2C Sensor anzubinden.

Auf CCU Seite bräuchte das Ganze dann aber wahrscheinlich ein komplett neues XML File, wo ich überhaupt keine Ahnung habe, ob und wie das möglich ist.
Wenn ich aber den Universalsensor anschaue, muß es ja gehen.