AskSin++ Library

[Tom Major]

Hallo papa und Linef,
bezüglich Ruhestrom, ich will das jetzt hier nicht weiter ausreizen da OT, ich war nur der Meinung das z.B. beim use case Temp.sensor, der z.B. alle 10 min seinen Temp.wert schickt, der Unterschied zwischen 0,5 uA und 4 uA Ruhestrom (und auch das kurze Aufwachen alle 8sec) nicht so wichtig ist für den Batterieverbrauch, da der Löwenanteil für das Senden draufgehen wird. Hätte ich Zahlen für die Sendedauer einer weather msg könnte man das auch mal kalkulieren. Bei einer Fernbedienung die fast nie sendet sondern nur daliegt wäre das natürlich was anders, da würde sich ein grosser Laufzeitunterschied mit einer Batterie ergeben.

Ich hätte 2 Fragen, zum einen stehe ich mit jp112sdl in Kontakt bezüglich seiner example sketche, und da ist uns folgendes aufgefallen. Er hat als Basis für seinen HM-WDS10-TH-O DS18B20 sketch einen Stand von papa vom November benutzt, da wurde u.a. folgender code verwendet:

Code Auswählen Erweitern


class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL,List0>, public Alarm {


Heute sieht diese Stelle so aus

Code Auswählen Erweitern


DEFREGISTER(WeatherRegsList0,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL,WeatherList0>, public Alarm {


Was genau bewirkt diese Änderung, hat das was mit Burst mode für die HM-CC-RT-DN zu tun? Und brauche ich die nicht wenn ich keine HM-CC-RT-DN direkt peere?

Und zweitens, ich habe heute mal mit meinen Testaufbau den HM-WDS10-TH-O programmiert. Temp.werte und Feuchtigkeit kommen an, genial, aber kann mir vielleicht jemand sagen warum ich den Batteriestatus nicht in der ccu2 (RaspberryMatic) sehe? Beim Wassermelder gibt es beim Device ein Feld 'Batterie ok' aber bei diesen Temp.sensor nicht?
Ich weiß, ist keine FHEM sondern eine HM Frage, aber vielleicht weiß es ja trotzdem jemand hier.

Danke,

[papa]

Was genau bewirkt diese Änderung, hat das was mit Burst mode für die HM-CC-RT-DN zu tun? Und brauche ich die nicht wenn ich keine HM-CC-RT-DN direkt peere?

Wahrscheinlich gar nichts - ich habe das bis dahin fehlende Register BurtRX mit eingebaut. Es wird aber noch nicht beachtet. Hm - aber eigentlich fehlen jetzt die Register für die MasterID ... müste eigentlich so sein

Code Auswählen Erweitern

DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)


Und zweitens, ich habe heute mal mit meinen Testaufbau den HM-WDS10-TH-O programmiert. Temp.werte und Feuchtigkeit kommen an, genial, aber kann mir vielleicht jemand sagen warum ich den Batteriestatus nicht in der ccu2 (RaspberryMatic) sehe? Beim Wassermelder gibt es beim Device ein Feld 'Batterie ok' aber bei diesen Temp.sensor nicht?
Ich weiß, ist keine FHEM sondern eine HM Frage, aber vielleicht weiß es ja trotzdem jemand hier.

Gute Frage. Das könnte ein Fehler auf RaspberryMatic-Seite sein, da der Sensor ja nur das Battery-Low-Bit setzt. Die Auswertung erfolgt auf der Empfängerseite. Vielleicht liegt es aber auch an den fehlenden Registern für die Addresse der Master - das gehört eigentlich immer in die Liste 0.

[jp112sdl]

Gute Frage. Das könnte ein Fehler auf RaspberryMatic-Seite sein, da der Sensor ja nur das Battery-Low-Bit setzt.

Das ist kein Fehler, sondern ein Feature und auch nicht nur bei RaspberryMatic sondern auch bei der CCU2 so.
Bei einigen wenigen Geräten wird unter "Status und Bedienung" -> "Geräte" das Feld für den Batteriezustand mit angezeigt.
So u.a. beim HM-Sec-WDS und HM-WDS30-OT2-SM.
Bei anderen Geräten (kapazitiver Füllstandssensor, Fensterkontakte, Energiezähler, Kontaktinterface) wiederum nicht.
Was auch immer man sich dabei gedacht hat...

[Tom Major]

Das ist kein Fehler, sondern ein Feature und auch nicht nur bei RaspberryMatic sondern auch bei der CCU2 so.
Bei einigen wenigen Geräten wird unter "Status und Bedienung" -> "Geräte" das Feld für den Batteriezustand mit angezeigt.
So u.a. beim HM-Sec-WDS und HM-WDS30-OT2-SM.
Bei anderen Geräten (kapazitiver Füllstandssensor, Fensterkontakte, Energiezähler, Kontaktinterface) wiederum nicht.
Was auch immer man sich dabei gedacht hat...

Ok, verstanden, danke für den Hinweis.

[Tom Major]

Wahrscheinlich gar nichts - ich habe das bis dahin fehlende Register BurtRX mit eingebaut. Es wird aber noch nicht beachtet. Hm - aber eigentlich fehlen jetzt die Register für die MasterID ... müste eigentlich so sein
DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)

Ok, es sollte also die MASTERID_REGS mit in den HM-WDS10-TH-O sketch rein?
Eine kurze Suche zeigt übrigens das MASTERID_REGS aktuell nur in 6 von 15 HM-... example sketeches verwendet wird.

[papa]

Ok, es sollte also die MASTERID_REGS mit in den HM-WDS10-TH-O sketch rein?
Eine kurze Suche zeigt übrigens das MASTERID_REGS aktuell nur in 6 von 15 HM-... example sketeches verwendet wird.

Es gibt noch Examples, die nutzen die alte List0 Implementierung.

[Tom Major]

In den letzten Tagen haben jp112sdl und ich uns mit einem universellen HM Sensor auf Basis der AskSin++ beschäftigt.
Im verlinkten Arduino sketch werden als Demo dummy Werte generiert und an die CCU2 gesendet. Aufbauend auf dem sketch kann man die Messwerte beliebiger Sensoren selbst einbauen. Anpassen muss man nur den sketch selbst und für die Darstellung in der CCU2 die Datei hb_uni_sensor1.xml.
Vielleicht hilft es ja jemanden.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1

Vielen Dank an papa, jp112sdl, Dirk und andirs für die Anregungen und Hilfestellungen.

[LuBeDa]

In den letzten Tagen haben jp112sdl und ich uns mit einem universellen HM Sensor auf Basis der AskSin++ beschäftigt.

Das ist richtig Klasse!!!

Genau das was ich brauche.

Nur..... was muss ich machen damit FHEM auch die Kanäle Temperatur 1 -4 , Humity, Pressure richtig versteht? Ich habe mal bei Homebrew Wired etwas gefunden und werde noch nicht daraus schlau wie man sein eigenes Homematic-Modul für Homebrew Geräte programmiert. Die XML alleine wird wohl nicht ausreichen.

Ludger

[papa]

Tja - das ist leider das Problem. Man braucht immer eine Erweiterung. Ich köknnte mir aber auch ein generisches Sensordevice vorstellen, wo die Payload einer Sensornachricht (Typ 0x53) durch ein/mehrere Attribut(e) beschrieben und dann entsprechend in einzelne Readings aufgeteilt wird.

Code Auswählen Erweitern


valueSze = 2:4:4
valueFactor = 10:1:1
valueName = Temperatur:Licht:Druck


Es werden 3 Werte übertragen - 2 Byte mit der Temperatur, 4 Byte Licht und 4 Byte Druck. Der Temperaturwert muss noch durch 10 geteilt werden.

[jp112sdl]

Tja - das ist leider das Problem. Man braucht immer eine Erweiterung.

Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.

[Tom Major]

Das ist richtig Klasse!!!
Genau das was ich brauche.
Nur..... was muss ich machen damit FHEM auch die Kanäle Temperatur 1 -4 , Humity, Pressure richtig versteht? Ich habe mal bei Homebrew Wired etwas gefunden und werde noch nicht daraus schlau wie man sein eigenes Homematic-Modul für Homebrew Geräte programmiert. Die XML alleine wird wohl nicht ausreichen.
Ludger

Bei mir läuft zur Zeit FHEM und RaspberryMatic parallel und ohne connection, da ich bezüglich HomeMatic und seinen Devices noch im Testmodus bin.

Ich könnte Dir aber HMConfig_SenTHPL.pm aus dem Universalsensor so anpassen, dass es für das Demo mit Temperatur 1 -4 , Humity, Pressure laufen sollte, testen kann ich es aber nicht. Bin nicht 100% sicher ob das für FHEM ausreicht aber ich glaube schon. Wenn Du das machen willst dann sag Bescheid. Du brauchst natürlich eine lauffähige Sensor HW (z.B. Arduino Pro Mini und CC1101) für den Test.

[papa]

Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.

Addon ist ja auch ok - aber bei FHEM ist es Code, der gebaucht wird. Die XML Files gehen für Homematic nicht.

[jp112sdl]

Die XML Files gehen für Homematic nicht.

Reden wir von denselben XML Files?
Dieses XML File hier zB
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/CCURM_Install/HB-UNI-Sensor1_CCURM-addon-src/addon/firmware/rftypes/hb_uni_sensor1.xml
funktioniert wunderbar mit Homematic.

[papa]

Ja für die CCU . aber es war ja die Frage nach FHEM Integration.

[jp112sdl]

Ja für die CCU . aber es war ja die Frage nach FHEM Integration.

Ok, dann hab ich es nur falsch rum verstanden.