AskSin++ Library

[efyzz]

Moin,

ich versuche mal mit meinem gefährlichen Halbwissen etwas dazu zu sagen 

Die AsksinPP Projekte basieren auf einem Atmega 328. Verstehe ich Dich richtig, dass Du ein original Homematic Gerät mit einem AsksinnPP Sketch flashen willst? Das wird wohl aus verschiedensten Gründen nicht kompatibel sein ...

[papa]

Hi,
ich habe hier ein HM-PBI-4-FM mit defektem Funkmodul. Das Modul habe ich getauscht (Aus einem defekten Fenstersensor) und nun kann ich das Teil sehen.... dummerweise verschlüsselt.
Ich wollte nun den Sketch "HM-PBI-4-FM" vom Jérôme nehmen.... der ist leider zu groß...

Der Sketch verwendet 18684 Bytes (130%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes.

(Im Modul ist ein Atmega 168PA drin). Es gab irgendwo mal einen Beitrag wie man da vielleicht weiterkommt, ich finde den aber nicht mehr.

Besteht überhaupt eine Möglichkeit den Sketch so weit abzuspecken das man 4K Programmspeicher spart?

Schau mal in Jeromes Repository, da gibt es auch Geräte mit 168. Auf jeden Fall geht AES dort nicht.
Es gibt ein paar Defines, welche Einfluss auf die Codegröße haben. Infos findest Du hier https://github.com/pa-pa/AskSinPP?tab=readme-ov-file#defines-to-reduce-code-size

[Funsailor]

Moin,

ich versuche mal mit meinem gefährlichen Halbwissen etwas dazu zu sagen 

Die AsksinPP Projekte basieren auf einem Atmega 328. Verstehe ich Dich richtig, dass Du ein original Homematic Gerät mit einem AsksinnPP Sketch flashen willst? Das wird wohl aus verschiedensten Gründen nicht kompatibel sein ...

Nicht ganz richtig, siehe auch Papas Antwort
Wenn man da etwas hoch scrollt, findet man das:

Code Auswählen Erweitern

C++ implementation of the AskSin protocol

    easy configuration of the device channels by using templates
    direct eeprom access for the channel data
    AES signature support
    Supported MCU:
        ATMega328
        ATMega32 (Standard Pinout)
        ATMega128 (Standard Pinout)
        ATMega644 (Bobuino Pinout is highly suggested)
        ATMega1284 (No OTA Bootloader support, yet)
        STM32F1
        ESP32 (not fully implemented)
        RP2040 (not fully implemented)


[Funsailor]

Hi Papa,
danke für den Tip, ich habe die entsprechenden Sketche in Jeromes Repository gefunden.
Wenn ich die folgenden Zeilen aus den entsprechenden Dateien nutze:

Code Auswählen Erweitern

#define SENSOR_ONLY
#define NORTC
#define NOCRC
#define SIMPLE_CC1101_INIT
#define NDEBUG

#define EI_NOTEXTERNAL
#define EI_ATTINY24

//saves ~646 bytes program size:
extern "C" void *malloc(size_t size) {return 0;}
extern "C" void free(void* p) {}
passt der Sketch in den 168er....

Allerdings wird dann nicht mehr viel funktonieren, da mit dem Macro
EI_ATTINY24 einige wichtige Funktionen in der EnableInterrupt.h wegfallen    

Ohne das Macro wird der Sketch ein wenig zu groß ... : 15166 Bytes (105%)

Allerdings habe ich alle 168er Sketche in Jeromes Repository versucht zu compilieren, die werden alle zu groß 

[frank]

https://homematic-forum.de/forum/viewtopic.php?f=76&t=67975&start=10#p798043

edit:
gerade noch gesehen.
die frage dort war ja sowieso von dir.

[raspifhem]

Hallo papa,
danke für das Projekt und die tolle Arbeit! Ich betreibe mittlerweile acht AskSin-Module und bin jedes Mal begeistert von der Nützlichkeit und Einfachheit. Super geeignet für größere Reichweiten, Zuverlässigkeit und/oder Batteriebetrieb.

Die Module senden ungefähr alle drei Minuten Werte. Für meinen Anwendungsfall und um Energie zu sparen würde mir ein längerer Zeitraum (beispielsweise eine Stunde) ausreichen. Wie ändere ich das Sendeintervall?

Ich entschuldige mich vorab, falls die Frage schon beantwortet wurde - habe den Code inspiziert und viele der über 100 Seiten hier gelesen, die Antwort aber leider nicht gefunden oder übersehen. Danke.

[papa]

Die Module senden ungefähr alle drei Minuten Werte. Für meinen Anwendungsfall und um Energie zu sparen würde mir ein längerer Zeitraum (beispielsweise eine Stunde) ausreichen. Wie ändere ich das Sendeintervall?

Um welches Gerät / Sketch handelt es sich genau ?

[raspifhem]

Ich nehme meistens die Vorlage für "Device Model: HM-WDS40-TH-I" und setze dann statt Temperatur/Humidity meine Sensorwerte.

[papa]

Das kommt dann aus dem WeatherChannel. Dieser berechnet den nächsten Sendezeitpunkt in der reactivate() Methode:
https://github.com/pa-pa/AskSinPP/blob/df66809b243180f374692421ad3a44cb3f5c5f6f/Weather.h#L50

Du könntest im Sketch EXTRADELAY in ms definieren. Vielleicht kommst Du damit ja hin.

[raspifhem]

Ein

Code Auswählen Erweitern

#define EXTRADELAY 3600000 oder

Code Auswählen Erweitern

typedef WeatherChannel<Hal, SysClock, Sensors, PEERS_PER_CHANNEL, EXTRAMILLIS+EXTRADELAY, WeatherList0> ChannelType; hat leider keine Änderung bewirkt.

Ich werde mal weiter forschen wo die drei Minuten herkommen.

[papa]

Trag mal beim Typedef den Wert direkt ein.

[raspifhem]

Lässt sich eigentlich ein HM-WDS40-TH-I und ein HM-LC-SW2-FM kombinieren und in FHEM per CUL_HM einbinden? Ich frage dies, weil ich einen Asksin-Sender mit Temp-/Hydro-Sensor (HM-WDS40-TH-I) betreibe und ihn gerne um einen Aktor (HM-LC-SW2-FM) zum Schalten einer LED/Summer erweitern würde.

[loetmeister]

Hi,

kurze Frage... bei Dimmer.h Zeile 605 https://github.com/pa-pa/AskSinPP/blob/master/Dimmer.h#L605
bei case AS_CM_ACTIONTYPE_TOGGLE_INVERSE_TO_COUNTER: - müsste der Vergleich nicht "(counter & 0x01) == 0x00 ? ..." wie bei AS_CM_ACTIONTYPE_TOGGLEDIM_TO_COUNTER_INVERSE sein?
Oder verhält sich TOGGLE INVERSE und TOGGLEDIM INVERSE unterschiedlich?

Gruß,
Thomas

[papa]

Da könntest Du Recht haben. Hat bestimmt noch niemand genutzt und deshalb ist es nicht aufgefallen.

[loetmeister]

Hallo papa,

ja, stimmt.... wird vermutlich nicht so oft benutzt.
Bin aktuell dran meine etwas unvollständige state engine für HM Wired (https://github.com/ThorstenPferdekaemper/HBWired) mit Hilfe deiner AskSinPP Lib (Switch.h, etc.) zu aktualisieren. Meine Referenz ist ein HMW-LC-Sw2-DR, da teste ich verschiedene Aktionen.

Ich will jetzt nicht hier weiter einzelne Codezeilen zur Diskussion stellen.... aber zwei Sachen ist mir noch aufgefallen... wobei es da eventuell unterschiede zu Wired und Funk gibt? 

Wenn ein "set toggle" im Status AS_CM_JT_OFFDELAY kommt, dann würde auf AS_CM_JT_ON gewechselt. (https://github.com/pa-pa/AskSinPP/blob/master/Switch.h#L211) - da der Ausgang aber bereits eingeschaltet ist wäre keine Änderung sichtbar. HMW-LC-Sw2 wechselt in diesem Fall auf OFF. Bei ONDELAY entsprechend zu ON. Hier würde auch on/off Time aus dem peering gesetzt (nicht statisch DELAY_INFINITE)

Es scheint als würde ONDELAY als OFF behandelt, OFFDELAY als ON - bzgl. der Steuerung des Ausgangs. Das spiegelt sich auch im "Jump To Target" wieder - bei einem direkten Sprung von onDelay (Ausgang Aus) zu offDelay wird der Ausgang eingeschaltet (war zuvor aus). Entspr. bei ON -> offDelay -> onDelay geht der Ausgang beim starten des onDelay auf Aus.


Nutze einen Teil deines Codes in der HBWired Lib... hoffe das ist ok.  (HBWSwitchAdvanced.h /cpp https://github.com/loetmeister/HBWired/tree/dev/libraries/src - noch in meinem dev branch). Dimmer (HBWDimmerAdvanced) kommt als nächstes...

Gruß,
Thomas