AskSin++ Library

[papa]

Customsensor mit Temperatur, Luftfeuchtigkeit und Batteriespannung funktioniert. Der Zeitintervall lässt sich auch einstellen.

Super - danke für die Rückmeldung

[gloob]

Super - danke für die Rückmeldung

Kann es sein, dass das Updateinterval erst nach einem "Reset/Neustart" des Sensors übernommen wird?
Und wofür braucht es das "max" auf 15 Sekunden?

Code Auswählen Erweitern

uint8_t delay = max(15,this->getList1().eventDelaytime());

[papa]

Kann es sein, dass das Updateinterval erst nach einem "Reset/Neustart" des Sensors übernommen wird?

Nein, aber der gerade aktive Delay wird noch abgewartet - also wenn es 2 Minuten waren und Du auf 30 Sekunden änderst, musst Du maximal nochmal die 2 Minuten warten, dann wird beim nächsten Zyklus auf die 30 Sekunden gewechselt.

Und wofür braucht es das "max" auf 15 Sekunden?

Code Auswählen Erweitern

uint8_t delay = max(15,this->getList1().eventDelaytime());

Damit der Sensor nicht den gesamten Funkverkehr blockiert. Wahrscheinlich müsste man noch länger warten - 1% Regel

[gloob]

Das klingt beides Plausibel. Vielen Dank.

[jp112sdl]

Damit der Sensor nicht den gesamten Funkverkehr blockiert. Wahrscheinlich müsste man noch länger warten - 1% Regel

Ich hab das auch mal durchgerechnet.
Ein Telegramm mit maximaler Länge (17 Byte Payload) (ohne Burst, ohne AES) dauert 30ms.
1% einer Stunde hat 36 Sekunden bzw. (36 * 1000ms) / (30ms / Telegramm) = 1200 Telegramme je Stunde oder halt auch alle 3 Sekunden ein Telegramm.
Alles bezogen auf 1x ausgesendete Messages (bei BIDI: Erfolg beim 1. Versuch).
Arbeitet man allerdings mit (bis zu 10) Wiederholungen bei Fehlschlägen, dann hat man u.U. schon 30 Sekunden voll.

Bei Burst kommen noch mal 360ms oben drauf und bei AES auch noch mal ~250ms.

[gloob]

Ist die Größe einer Message z.B. beim Universalsensor eigentlich begrenzt?

Code Auswählen Erweitern

// add battery voltage
msg.add(device().battery().current());

// add temperature value
msg.add(sht10.temperature());

// add humidity value
msg.add(sht10.humidity());

...

Ich würde im Moment gerne folgende Werte schicken:

Code Auswählen Erweitern

Temperature: int16_t
Humidity: uint8_t
Brightness: uint32_t
BatteryVoltage: uint8_t
Distance: uint32_t

Allerdings können da gerne noch schnell ein paar dazu kommen.

[Tom Major]

Ist die Größe einer Message z.B. beim Universalsensor eigentlich begrenzt?

Ich habe bei mir im HB-UNI-Sensor1.ino in Message::init(..) diesen Kommentar drin, den ich irgendwo gelesen hatte, weiß leider nicht mehr genau woher und wie glaubwürdig die Info ist:

Code Auswählen Erweitern

// max. msg length 0x19 ?

[jp112sdl]

Die maximale Länge eines Telegramm beträgt 26 Byte, wovon bis zu 17 Byte Nutzdaten sein können.

Der Aufbau ist grob dargestellt:
LENGTH(1) - MSGCOUNTER(1) - CONTROL(1) - FRAMETYPE(1) - SENDER(3) - RECEIVER(3) - PAYLOAD(1-17)
Wobei das erste Byte "LENGTH" nicht mit in die Telegrammlänge eingerechnet wird.


Sehr interessante Detailinformationen gibt es beim CCC: https://media.ccc.de/v/30C3_-_5444_-_en_-_saal_g_-_201312301600_-_attacking_homematic_-_sathya_-_malli
Sowie zur Staffelung des Sendeverhaltens hier: https://www.youtube.com/watch?v=uAyzimU60jw

[Tom Major]

Sehr interessante Videos.
Beim 2. Video ist bei ca. 10 min die max. payload von 17 Bytes erwähnt.

Die Message Length im ersten Parameter bei papas Message::init() Funktion müsste sich m.E. so berechnen:

Code Auswählen Erweitern

11 + payload
hier ist der overhead 11 Bytes im Gegensatz zu den 9/10 Bytes aus

LENGTH(1) - MSGCOUNTER(1) - CONTROL(1) - FRAMETYPE(1) - SENDER(3) - RECEIVER(3)

[Xent]

Soo, hab jetzt endlich die Fernbedienung da.
Soweit funktioniert auch alles allerdings ist mir aufgefallen, dass wenn der Aktor meint, dass das Rollo zu 100% auf bzw komplett unten ist, dann löst er nicht mehr aus.
Bei den originalen Aktoren ist es so, dass sie sich trotzdem noch für ne Sekunde oderso einschalten, damit man mögliche Fehler in der Position des Rollos beheben kann.

Wie schaut es eigentlich mit Kalibrierungsfahrten aus?
Kann man das auch schon einstellen bzw. fährt er bei kompletten zu Ständen also komplett Auf/Zu, etwas länger um mögliche Fehler bei der Position zu korrigieren?

[papa]

Soo, hab jetzt endlich die Fernbedienung da.
Soweit funktioniert auch alles allerdings ist mir aufgefallen, dass wenn der Aktor meint, dass das Rollo zu 100% auf bzw komplett unten ist, dann löst er nicht mehr aus.
Bei den originalen Aktoren ist es so, dass sie sich trotzdem noch für ne Sekunde oderso einschalten, damit man mögliche Fehler in der Position des Rollos beheben kann.

Das sollte eigentlich genau so funktionieren. Habe das aber bisher bur mit den internen Tastern probiert. Kann sein, dass es bei der Fernbedienung noch Probleme gibt.

Wie schaut es eigentlich mit Kalibrierungsfahrten aus?
Kann man das auch schon einstellen bzw. fährt er bei kompletten zu Ständen also komplett Auf/Zu, etwas länger um mögliche Fehler bei der Position zu korrigieren?

Die Fahrzeit wird über die Register refRunningTimeButtonTop bzw. refRunningTimeTopButton eingestellt.

[Xent]

Das ist mir klar, dass die Zeiten damit eingestellt werden.
In der CCU kann man aber einstellen dass nach x Fahrten wo nur eine bestimmte Position angefahren wurde, eine Kalibrierungsfahrt gemacht wird und alle kompletten fahrten also 0% oder 100% auch als Kalibrieringsfahrt gelten.
Also müssten diese ja etwas länger als normal ausfallen, damit kleine Fehler behoben werden.


Ich werd mal nen internen Taster testen und schauen ob dann was gesendet wird.
Per Funk bekomme ich zwar ne Rückmeldung geschickt, aber es wird nichts ausgelöst.

[papa]

Das ist mir klar, dass die Zeiten damit eingestellt werden.
In der CCU kann man aber einstellen dass nach x Fahrten wo nur eine bestimmte Position angefahren wurde, eine Kalibrierungsfahrt gemacht wird und alle kompletten fahrten also 0% oder 100% auch als Kalibrieringsfahrt gelten.
Also müssten diese ja etwas länger als normal ausfallen, damit kleine Fehler behoben werden.

Ach das meinst Du - das ist nicht implementiert. Müsste man mal schauen, wo das gut einzubauen geht.

Ich werd mal nen internen Taster testen und schauen ob dann was gesendet wird.
Per Funk bekomme ich zwar ne Rückmeldung geschickt, aber es wird nichts ausgelöst.

Schau mal in Blind.h BlindStateMachine::calcDriveTime wird sichergestellt, dass mindestens 2 Sekunden gefahren wird. Also wenn der State Change von On -> nach DelayOn und weiter nach RampOn kommt, wird immer mindestens 2 Sekunden gefahren. Schau die mal die Register an, ob er auch in ON-State beim Tastendruck nach DelayOn geht.

[Xent]

Soo, habe nun denke ich nen Fix dafür gefunden.
Wenn ich in der Zentrale auf oder ab drücke, dann wird das level entweder auf 0 oder 200 gesetzt.
Wenn es aber laut Aktor schon 0 ist, wird nichts in der Funktion setDestLevel ausgelöst.

Habe nun eingebaut, dass er bei kompletten Fahrten trotzdem auslöst.
Dann fährt er die 2 Sekunden die du angesprochen hast.

Code Auswählen Erweitern

void setDestLevel (uint8_t value) {
    destlevel = value;
    if( destlevel > level || level == 200 ) {
      setState(AS_CM_JT_ONDELAY, 0);
    }
    else if ( destlevel < level || level == 0) {
      setState(AS_CM_JT_OFFDELAY, 0);
    }
  }


https://www.elv.de/faq/homematic-rollladenschalter-kalibrierfahrt.html
https://www.elv.de/topic/frage-zu-homematic-rollladen-jalousie-aktor-hm-lc-bl1-fm-funk-rollladenaktor-1fach-unterputzmontage.html

[Xent]

Hab gerade bemerkt, dass ich nen Fehler drin hatte ...

Code Auswählen Erweitern

void setDestLevel (uint8_t value) {
    destlevel = value;
    if( destlevel > level || destlevel == 200 ) {
      setState(AS_CM_JT_ONDELAY, 0);
    }
    else if ( destlevel < level || destlevel == 0) {
      setState(AS_CM_JT_OFFDELAY, 0);
    }
  }


Irgendwie klappt da konfigurieren auch noch nicht so recht.
Könnte am XML liegen, da scheinbar noch nicht mal was von der CCU gesendet wird.
Es wird die ganze Zeit nur der Ladebalken für "Daten werden übertragen" angezeigt und der Schalter lässt sich inder GUI nicht konfigurieren.