AskSin++ Library

[Tom Major]

Gelten die 4uA für den Ardunio alleine oder ist da der Verbrauch des CC1101 schon mit eingerechnet?
Schickt die Lib den CC1011 normalerweise schlafen? Ich frage daher weil ich auch etwa 4uA im sleep alleine für den Arduino erreiche.
Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...

Die 4 uA gelten für den Arduino (LDO und power LED raus). Das ist der power down Modus mit ext. Quarz (8 MHz in dem Fall), die 4 uA werden für den watchdog OSC benötigt der das Teil ja wieder aufwecken muss.
Mit int. OSC statt 8 MHz und 32kHz als RTC kann man den watchdog disablen da dann die RTC wecken kann. Dann kommt man auf ca. 1 uA.
CC1101 wird von papas lib in den sleep geschickt, der braucht dann überhaupt keinen Strom, < 1uA, müsste im Datenblatt nachschauen.

Sensoren müssen normalerweise nicht extra abgeschaltet werden, kommt natürlich auf den Sensor an.
Bei meinem Universalsensor mit momentan DS18x20 und BME280  (Helligkeit kommt noch) ist das nicht nötig.

[papa]

Das kommt ganz auf den verwendeten Sleep-Mode an. Im sparsamsten Modus wird das CC1101 abgeschaltet, wenn es nicht gebraucht wird. Dafür kann man dann auch nicht mehr so einfach durch den Funk aufgeweckt werden.

[Wzut]

Habe das originale so modifiziert dass es zu meiner payload aus dem Universalsensor passen müsste und erstmalig bei mir eingecheckt, schau es Dir mal an, im Ordner FHEM:

Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.
Unklar ist mir jetzt noch : wie bekomme ich elegant einen Sollwert von FHEM Richtung Sensor und wie finde ich ihn im Sensor zur Verarbeitung wieder ?
Den Part mit regSet und dem Register lowBatLimitTHPL konnte ich auf FHEM Seite zumindest nachvollziehen, der Wertebereich ist zwar z.Z auf 1-5 beschränkt, ist aber für die ersten Versuche egal. Der Unisensor  macht das mit dem alitude wohl genau so. OK, zusammen mit der nun funktionierenden LayzConfig eine mögliche Variante um Werte zum Sensor zu bekommen. Es muss aber doch auch noch eleganter gehen wie z.B. bei einem Rolloaktor, wo man einfach mit Set <Device> pct X den Wert übermitteln kann (Mir ist klar das der Sensor dann nicht im Tiefschlaf sein darf um das Telegramm auch verarbeiten zu können)   

[papa]

Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.
Unklar ist mir jetzt noch : wie bekomme ich elegant einen Sollwert von FHEM Richtung Sensor und wie finde ich ihn im Sensor zur Verarbeitung wieder ?
Den Part mit regSet und dem Register lowBatLimitTHPL konnte ich auf FHEM Seite zumindest nachvollziehen, der Wertebereich ist zwar z.Z auf 1-5 beschränkt, ist aber für die ersten Versuche egal. Der Unisensor  macht das mit dem alitude wohl genau so. OK, zusammen mit der nun funktionierenden LayzConfig eine mögliche Variante um Werte zum Sensor zu bekommen. Es muss aber doch auch noch eleganter gehen wie z.B. bei einem Rolloaktor, wo man einfach mit Set <Device> pct X den Wert übermitteln kann (Mir ist klar das der Sensor dann nicht im Tiefschlaf sein darf um das Telegramm auch verarbeiten zu können)

Auf der AskSin++ Seite musst Du nur einfach

Code Auswählen Erweitern

  bool Channel::process (const ActionSetMsg& msg) {}
für die Channel Klasse implementieren. Der BlindChannel macht einfach ein

Code Auswählen Erweitern

  bool process (const ActionSetMsg& msg) {
    setDestLevel( msg.value() );
    return true;
  }
Wie man das ganze jetzt von FHEM aus triggert, ist mir noch nicht wirklich klar.

[Tom Major]

Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...

Wenn Du das in der sketch loop() drin hast

Code Auswählen Erweitern


// if nothing to do - go sleep
hal.activity.savePower<Sleep<>>(hal);

sollte der CC1101 < 1uA ziehen..

[Tom Major]

Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.

Hast Du zufällig mal geschaut ob mein modifiziertes FHEM Modul alle Sensorwerte zu FHEM durchroutet?
Konfigurierbare Höhe baue ich heute abend ein.

[Wzut]

Hast Du zufällig mal geschaut ob mein modifiziertes FHEM Modul alle Sensorwerte zu FHEM durchroutet?

ja mir fehlten bisher die letzten beiden Werte (batVoltage und Helligkeit), nach der Anpassung im FHEM Modul habe ich
zum einen jetzt batVoltage mit Werten (war vorher immer 0.00) und ein neues Reading  brightness mit meinem Testwert.

[Tom Major]

ok, habe den BME280 im Universalsensor integriert und die Höhe für die Luftdruckberechnung (NN) konfigurierbar gemacht.
Sensor läuft und Höhe lässt sich über WebUI einstellen.

Habe auch das FHEM Modul an das von mir verwendete Register angepasst:

Code Auswählen Erweitern


$HMConfig::culHmRegDefine{'altitude'}     = {a=>34.0,s=>2.0,l=>0,min=>0   ,max=>10000 ,c=>'',f=>'',u=>'m'  ,d=>0,t=>'Altitude for calculate air pressure at see level in meter.'};

@Wzut, kannst mal testen ob die Höhe damit auch von FHEM änderbar ist.

[papa]

ok, habe den BME280 im Universalsensor integriert und die Höhe für die Luftdruckberechnung (NN) konfigurierbar gemacht.
Sensor läuft und Höhe lässt sich über WebUI einstellen.

Könntest Du das bitte als Sensor-Klasse für die Lib zur Verfügung stellen ? Den BMP180 gibt es ja schon. Gegebenenfalls müsste man die API für die Berechnung mit der eigenen Höhe noch anpassen.

[Wzut]

@Wzut, kannst mal testen ob die Höhe damit auch von FHEM änderbar ist.

Ja kann ich heute Abend machen, allerdings ist das IMHO für FHEM nicht so wichtig. Der bestehende Unisensor geht den Weg über das globale Attribut altitude um NN als Reading zur Verfügung zu stellen. D.h. die Berechnung findet auf FHEM Seite statt und nicht im Sensor.

[Tom Major]

Könntest Du das bitte als Sensor-Klasse für die Lib zur Verfügung stellen ? Den BMP180 gibt es ja schon. Gegebenenfalls müsste man die API für die Berechnung mit der eigenen Höhe noch anpassen.

Ja gerne, wir müssten aber die Details der Einbindung abstimmen, am Besten per PM. Ich habe in meinem Universalsensor die 2 bisher verwendeten Sensoren über eigene Header files gemacht, da ich dafür volle Kontrolle außerhalb der Lib wollte.

[Tom Major]

Ja kann ich heute Abend machen, allerdings ist das IMHO für FHEM nicht so wichtig. Der bestehende Unisensor geht den Weg über das globale Attribut altitude um NN als Reading zur Verfügung zu stellen. D.h. die Berechnung findet auf FHEM Seite statt und nicht im Sensor.

Ja, ich habe es im FHEM Modul gesehen dass die NN Berechnung dort gemacht wird. Da die ausgewählte BME280 Lib aber NN Berechnung unterstützt habe ich es mal im Sensor mit vorgehalten, für nativen HM/RaspberryMatic Einsatz ist es schöner, bei Bedarf gleich den NN Luftdruck im Wetterkanal zu haben, dann braucht mon dort keinen script. Kann ja jeder im sketch selbst entscheiden welcher Luftdruck gesendet werden soll.

[MBHG]

Irre, der Thread ist jetzt schon 52 Seiten lang seit meinem ersten Reply.

Frage

HM-LC-SWX-SM & AES: ich hoffe / vermute wie ich gelesen habe, lediglich die Zeilen

Code Auswählen Erweitern

#define USE_AES
#define HM_DEF_KEY 0xab,0xcd,0xef,0x00,0x01,0x02(usw...)
#define HM_DEF_KEY_INDEX 0

einzufügen und anzupassen, indem ich den Key vom VCCU / CUL in Hex form für HM_DEF_KEY eingebe und dann paire korrekt? Aktuell (ohne die Definiton) finde ich die zugehörigen Register nicht.

Gruss Marc

[papa]

Wenn Du den HM Standardkey nimmst, kann HM_DEF_KEY_INDEX bei 0 bleiben. Wenn Du Deinen Key aus der VCCU einsetzt, musst Du auch den richtigen Index mit setzen.

[Klaus0815]

Ein kleiner Wunsch von mir, auch wirklich nur ein Wunsch, keine Aufforderung:
Ich würde mich riesig freuen wenn sich jemand erbarmen würde, das Ganze mal grob kurz zusammen zu fassen.
Es muss auch nicht Papa sein, der hat sicher genug um die Ohren, gibt wohl auch einige andere hier die sehr gut durchblicken

Ich würde gerne in das Thema Selbstbau von Homematic-Sensoren / Aktoren einsteigen.
Ziel des Ganzen wäre, die noch paar verbliebenen MySensors-Teile endgültig zu verbannen, da ständig Ärger damit

Flashen usw weiter traue ich mir grundsätzlich zu, löten usw alles kein Problem,
nur die Beispiele in Github verstehe ich zu wenig, die Bezeichnungen sagen mir nichts, sind wohl an Original-Homematic angelehnt.

Wäre interessiert an folgenden Teilen:
- Sensor mit DHT22 / DS18B20 o.ä. und Trigger für Taster oder Bewegungsmelder
- Sensor für mehrere Taster / Bewegungsmelder
- Sensor / Aktor zum ansteuern von 1-8 Relais, zusätzlich 1-8 direkte Tastereingänge, die die Ausgänge sofort schalten und auch direkt peerbar sind, also sofort schalten/ senden

Ob die Eingänge nachher open, tilted, on usw melden wäre mir egal bzw ich denke es wäre ein einfaches das dann zu ändern?
AES brauche ich erst mal nicht

Also, falls sich jemand erbarmen mag?
Viele Grüße

Klaus