AskSin++ Library

[Klaus0815]

Mir ist jetzt nicht klar, was Du eigentlich willst.

Hallo papa,  sorry wenn es etwas verwirrend war
Was ich bräuchte wäre quasi der Universalsensor zur Temperaturmessung, egal ob DS18B20, DHT22, BME280,...
Und dann zusätzlich ein Taster-Eingang,  dort kann ich dann z.B. einen Bewegunsmelder, einen Türkontakt, ein Taster der irgend eine Aktion auslöst anschließen

Szenario wäre z.B.:
- Habe im Bad (momerntan MySensors) einen Feuchtigkeitsmesser zur Ventilatorsteuerung, zusätzlich ist dort ein Taster um den Ventilator für 5 min anzuschalten

oder

- Auf der Terasse liegt ein Sensor - Temp+Luftfeuchte + Bewegungsmelder

Ich verstehe leider nicht wie ich das hinbekomme, der Sensor ist im deep-sleep, alle 5 min eine Temperatur-Messung, aber für den Taster / Bewegungsmelder muss ich ihn ja per Interrupt aufwecken?

Viele Grüße

Klaus

[MBHG]

Ich habe heute mal den UniSensor mit BMP280 und TSL2561 nachgebaut. Klappt alles auf Anhieb, inkl Plots. Super, vielen Dank.

Wie kann ich denn / muss ich die Meereshöhe einstellen?

Danke & Gruss

[kpwg]

Schau mal bei get regList und get regTable, was Du alles siehst. Ist da die Höhe (altitude) dabei?

Ich konnte bei meinem THPL Sensor mit BME280 und MAX44009 über getConfig // Config drücken // set regSet altitude 590 // Config drücken // getConfig // Config drücken die Höhe einstellen. Bitte berichtigt mich, wenn ich da zu viel drücke und mache- so hat es jedenfalls funktioniert 

Ich habe mittlerweile bereits im Sketch die Default-Höhe auf meine Seehöhe gesetzt und spare mir nun die Anpassung.

[Klaus0815]

Wie wird denn beim generischen Sensor die Batteriemessung mit eingebunden?

verstehe leider zu wenig von C++

Einfach das hier mit rein kopieren?

Code Auswählen Erweitern

  hal.battery.init(seconds2ticks(60UL*60), sysclock);
  hal.battery.low(22);
  hal.battery.critical(19);

[papa]

Das kommt ganz drauf an, wie die Spannungsversorgung aussieht. Wenn Du die Batteriesn direkt angeschlossen hast, wird die BatterySensor Klasse im HAL-Template genutzt. Wenn Du nen Stepup benutzt, musst Du noch den Spannungsteiler mit auf der Platine haben und nutzt die BatterySensorUni Klasse.
Die Batterieklasse muss dann noch initialisiert werden. Das hast Du aber schon gefunden. Als einfaches Beispiel für die direkte messung könnte der HM-SEC-MDIR.ino dienen.

[tndx]

Hallo zusammen,

ich kämpfe hier gerade auch mit der Spannungsmessung. Ich habe Dirks Außensensorplatine mit StepUp und will die eigentliche Batteriespannung messen, die entsprechenden Widerstände sind bestückt. Laut Schaltplan werden zur Messung die Ports A1 und D7 verwendet. Naiv wie ich bin, habe ich einfach "#define INTERNAL_VOLTAGE_MEASUREMENT" auskommentiert und habe erwartet, dass damit schon das richtige BatteryDevice zum Tragen kommt, wie im Forum bereits mehr fach an unterschiedlichen Stellen entdeckt:

Code Auswählen Erweitern

#ifdef INTERNAL_VOLTAGE_MEASUREMENT
typedef BatterySensor           BatteryType;
#else
typedef BatterySensorUni<5, 6>  BatteryType;
#endif
Doch damit werden bei mir die Werte zw. 5 und 12 gemessen, was nicht stimmen kann. Ich kann auch mit den beiden Ports 5 und 6 überhaupt nichts anfangen, keine mir bekannte Platine hier aus dem Forum nutzt diese Ports zur Messung. Da stellt sich mir die Frage, was für Port-Bezeichnungen werden hier erwartet? Atmega-Pinnummern, Arduino Pro Mini Pinnummern oder noch irgendwas Anderes? Bzw. was muss ich da konkret bei den Ports A1 und D7 angeben? Sind noch mehr Änderungen mit dem anderen BatteryDevice notwendig?

Sorry, bin nicht so der C++ Programmrierer 

Danke schonmal!

P.S.: Kompiliert wurde mit AskSinPP V3 vom 7.8.2018

[papa]

Die Batteryklasse erwartet Arduino-Pin-Nummern. Diese unterscheiden sich zwischen verschiedenen Boards. Für den Pro Mini ist A1 == 15 und D7 == 7. Es muss also

Code Auswählen Erweitern


typedef BatterySensorUni<15,7>  BatteryType;

heissen und der Pro Mini in der IDE eingestellt.sein.

[tndx]

Vielen Dank papa, läuft!

[Gruenebe]

Hallo papa,
funktioniert im V3 Branch der HM-SEC-RHS noch richtig?

Das Gerät lässt sich an der CCU anlernen, regiert aber nur auf Änderungen am Sabotage Pin.

Die Pins 14 und 15 werden in threestate.h unter readPin() erkannt. Es werden aber keine Statusänderungen an die CCU übertragen.

Laut ser. Mon sieht die Kommunikation bei Änderungen am Sabotagepin wie folgt aus:

<- 0E 08 A2 10 095634 45FB6E 06 01 C8 00 56  - 7606
waitAck: 00
<- 0E 08 A2 10 095634 45FB6E 06 01 C8 00 56  - 8242
-> 11 08 A0 02 45FB6E 095634 04 93 68 00 00 68 1A 02  - 8375
waitAck: 01


Bei einer Änderung an Pin 14 bzw. 15 wird nur der folg. 2er Block übertragen

<- 0C 05 A2 41 095634 45FB6E 01 04 00  - 5760
-> 11 05 A0 02 45FB6E 095634 04 65 29 00 00 29 0A 02  - 5893
waitAck: 01

Danke für einen Hinweis.

[papa]

Der Sketch sollte unverändert mit 2 Kontakten am Griff und einem Sabotage-Kontakt funktionieren.
Hast Du zufällig SENS3_PIN definiert ? Du musst hier dann einen zusätzlichen Kontakt anschliessen, der wie ein extra Fenster-Kontakt arbeitet. Also wenn dieser Kontakt offen ist - ist auch das Fenster immer im offen Zustand - egal wie der Griff steht. Es gibt dann keinen Sabotagekontakt.

[Gruenebe]

nein, Sens3 habe ich nicht definiert. Habe es so, wie im Beispiel als Standard gelassen.

[papa]

Wie ist die eventDelayTime konfiguriert ? Du musst den Pin mindestens so lange geändert lassen, wie die eventDelayTime eingestellt ist. Sonst wird immer nur der letzte Status übertragen. Also wenn Du den Pin nur ganz kurz schliesst, aber ein Delay von einer Sekunde eingestellt ist, kriegst Du immer nur den einen Status.

[Gruenebe]

die eventDelayTime habe ich nicht verändert.

Ich habe aber den Kontakt zu Pin 14 bzw. 15 dauerhaft geschlossen und es wird aber trotzdem nichts übertragen.

Wenn er sonst nur den letzten Zustand übertragen würde, müsste doch zumindest in der CCU Oberfläche die
"letzte Änderung" den aktuellen Zeitpunkt des kurzen Schliessens ausgeben?

[papa]

Irgendwelche anderen Änderungen am Code ?

[Gruenebe]

nein, habe heute extra nochmal den v3 Branch neu runtergezogen, das Example daraus genommen und neu kompiliert.
Einzig die beiden LEDs im Code liegen bei mir beide auf dem gleichen Pin, da ich an meinem Testboard nur eine LED an Pin4 hängen habe.
Das dürfte aber wohl keinen Einfluss auf die Ausführung des Codes haben.

Was mich aber etwas wundert, ist Dein Satz von vorhin:
"Also wenn dieser Kontakt offen ist - ist auch das Fenster immer im offen Zustand - egal wie der Griff steht. Es gibt dann keinen Sabotagekontakt."

Das ist zwar bei mir nicht der Fall, da kein Sens3 genutzt wird, aber wenn Du schreibst Kontakt offen = Fenster offen, würde doch bedeuten, dass Sens3 immer geschlossen sein muß,
wenn der Griff auf den Positionen Sens1 oder Sens2 steht.

Das führt mich nochmal zur generellen Frage der Beschaltung der Kontakte.

Ich gehe davon aus, dass die geschlossen auf GND gezogen werden und jeder nur einzeln schaltet. Also nicht Sens1 und Sens2 gleichzeitig geschlossen sein müssen, um einen bestimmten
Zustand zu signalisieren.

=>
Sens1 auf GND, Sens2 und Sab offen = "Fenster offen"
Sens2 auf GND, Sens1 und Sab offen = "Fenster Kippstellung"
Sab auf GND, Sens1 und Sens2 offen = "Sabotage"
alle offen = "Fenster verrriegelt"