AskSin++ Library

[kadettilac89]

Zum einen ist der Nano für 5V gebaut. Das geht aber nicht mit dem CC1101. Wird nur eine Spannung von 3,3V benutzt, ...

Du hast völlig Recht. Ich habe Nano mit den pro Mini 8 MHz verwechselt. Die pro Mini kann man ganz einfach modifizieren.

Kaum lötet man eine Weile nicht mehr an den Dingen rum, schon vergisst man ...

[StefanH]

papa hat natürlich vollkommen recht. Der Arduino Nano ist eigentlich nicht dafür geschaffen. Habe zwar den ATmega328p (p!), der extra energiesparend sein soll, aber bei 16MHz läuft er außerhalb seines spezifizierten Bereichs. Eigentlich wollte ich den Bootloader verändern, sodass er mit einem Prescaller von 2 läuft und somit mit 8MHz taktet, habe es aber leider nicht hinbekommen. Habe vorher noch nie einen Bootloader compiliert und bin vorerst daran gescheitert. Sonst hätte ich ihn als Arduino Mini programmieren können.
Das Homatic Hardware Projekt habe ich bereits vorher gesehen, wollte aber keinem die Mühe machen mir Platinen zu bestellen oder sie selbst zu bestücken, da mein FHEM noch ziemlich am Anfang steht. Dachte ein 3€ Arduino wäre erst einmal besser und mit weniger Aufwand verbunden.

@kadettilac89
eine Fernbedienung ist so aufgebaut, dass sie - in meinem Fall - 4 Outputs hat, welche dann über die Tasten auf die 8 Inputs geschaltet werden. Im Schlafmodus sind alle Outputs des Arduinos auf LOW geschaltet. Die 8 Inputs sind über Pin Change Interrupts überwacht. Wird eine Taster gedrückt, ändert sich einer der acht Inputpins auf LOW. Jetzt laufe ich in die ISR und schalte nach einander einen der vier Outputs auf LOW die anderen HIGH und überprüfe weiterhin den entsprechenden Inputpin. Damit bekomme ich heraus, welche Taster wirklich gedrückt wurde und rufe anschließend den Debouncing Algorithmus auf.
Den Code dazu kann ich gerne zur Verfügung stellen, ich bin aber kein besonders guter C++ Programmierer. Deswegen habe ich einfach nur das vorhandene Template erweitert... Somit ist mein Code jetzt nicht mehr kompatibel zu anderen Projekten.
Schick mir einfach eine PN, dann sende ich dir den Code zu inkl. einem Excel Blatt, in dem steht, wie  meine Knöpfe der Fernbedienung den einzelnen In- und Outputs zugeordnet sind.

[papa]

Könntest Du dafür nicht auch die Matrx Keypad Library verwenden ?

[StefanH]

Ja, die library scheint genau dafür gemacht zu sein. Kannte die noch gar nicht. Ich bin mir trotzdem nicht sicher ob es einfacher ist das Projekt so zu ändern dass man die library nutzen kann oder einfach die Funktionalität ins Projekt einbaut.

[Xent]

Ich hab gerade nen BUG gefunden, bin aber noch nicht dazu gekommen mir das mal anzuschauen ob ich das selbst fixen kann.

Ich habe den HM-LC-SWX-SM mit einem Taster direkt verknüpft.
Wenn ich nun den Taster lange drücke, sollte dies wie ein kurzer Tastendruck empfangen werden, egal wie lange ich auf den langen Taster drücke.
Da ich in der Verknüpfung aber eingestellt habe, dass getoggelt werden soll ist mir aufgefallen, dass der Aktor beim lange Drücken immer an und aus geht.
Der Taster sendet beim lange Drücken immer die gleiche Message mit dem gleichen Counter raus.
Darauf wird aktuell scheinbar nicht geprüft und die Message immer als neu interpretiert.

Hier mal die Messages:

Code Auswählen Erweitern

-> 0B 4B 84 40 3B1630 FE3456 45 69  - 464655
<- 0E 4B 80 02 FE3456 3B1630 01 01 C8 00 5C  - 464659
-> 0B 4C 84 40 3B1630 FE3456 45 69  - 464922
<- 0E 4C 80 02 FE3456 3B1630 01 01 00 00 5C  - 464925
-> 0B 4D 84 40 3B1630 FE3456 45 69  - 465189
<- 0E 4D 80 02 FE3456 3B1630 01 01 C8 00 5D  - 465192
-> 0B 4E A0 40 3B1630 FE3456 45 69  - 465457
<- 0E 4E 80 02 FE3456 3B1630 01 01 00 00 5B  - 465460


Zusätzlich wollte ich dich mal fragen, ob es ne Möglichkeit gibt den empfangenen LongPress zu überschreiben.
Also z.B. dass man bei kurz drücken Kanal 1 schaltet und beim lange Drücken Kanal 2.
Aktuell habe ich das über nen Programm in der CCU gemacht.

EDIT:
Irgendwie war scheinbar das Pairing defekt.
Nachdem ich jetzt noch etwas rumgespielt habe und ne Deckenlampe gepairt habe und wieder gelöscht habe usw.
Wird nur noch beim Loslassen der Taste ein Befehl zum FE3456 gesendet.
Allerdings wird nun das Halten der Taste zur Deckenlampe gesendet und diese schaltet sofort also schon vor dem Loslassen der Taste.

Vielleicht hast du ja was beim Pairing umgebaut oderso.
Ich weiß ja nicht ob man nem anderen Aktor mitteilen kann, dass der auch das Halten der Taste senden soll oder nur das Loslassen.

So sieht es mit Deckenlampe aus:

Code Auswählen Erweitern

ignore 0B 78 84 40 3B1630 46B031 45 19  - 413558
ignore 0B 79 84 40 3B1630 46B031 45 19  - 413826
ignore 0B 7A 84 40 3B1630 46B031 45 19  - 414093
ignore 0B 7B 84 40 3B1630 46B031 45 19  - 414360
ignore 0B 7C 84 40 3B1630 46B031 45 19  - 414627
ignore 0B 7D A0 40 3B1630 46B031 45 19  - 415044
ignore 0E 7D 80 02 46B031 3B1630 01 01 00 00 34  - 415171
-> 0B 7E A0 40 3B1630 FE3456 45 19  - 415341
<- 0E 7E 80 02 FE3456 3B1630 01 01 00 00 5C  - 415345

EDIT2:
Ich glaub ich komm so langsam dahinter wie das ganze tickt ...
Jenachdem welcher Aktor zuerst gepairt wurde, bekommt dieser die Meldungen für Taste lange gehalten.
Der andere bekommt nur die Meldung Taste lange losgelassen.

EDIT3:
Hab jetzt noch 1 Rollos auf den Taster gelegt.
Dieses reagiert gleichzeitig auf lange drücken, also muss der Aktor mitgeteilt bekommen dass er auch auf die andere Adresse hören soll.
Dies macht Asksin++ bisher noch nicht oder?

EDIT4:
Der Punkt mit dem Antworten auf die Gedrückt-Meldungen hat sich erledigt, ist im aktuellen master gefixt.
Allerdings toggled der Aktor noch beim Gedrückthalten.
Werd da mal nen Fix für commiten, damit der SwitchChannel die Messages ignoriert nach dem ersten Ausführen.
Für denk Punkt, dass man die LongPressAction überschreiben kann werd ich auch was bauen.

[papa]

Du kannst das Toggeln bei Long einfach abstellen, indem Du das lgActionType Register vom self auf inactive stellst. Dann sollte der SwitchChannel auf Long-Messages nicht mehr reagieren.

[Xent]

Daran hab ich noch garnicht gedacht.
Über den Expertenmodus der direkten Verknüpfung kann ich beim Kanal 1 einstellen dass er nicht auf Long reagieren soll und dann bei der 2. Verknüpfung mit dem 2. Kanal einstellen dass er nicht auf Short reagieren soll.
Aber ich fänds trotzdem ganz praktisch wenn man feststellen könnte ob der Status durch nen kurzen oder langen Tastendruck geändert wurde.
Vielleicht kann man bei dem switchState ja noch nen Flag hinzufügen oderso.


Zu dem Bug mit dem Toggeln, ich hatte folgendes im SwitchChannel umgebaut.
Natürlich noch die Variable in der Klasse hinzugefügt.
Dadurch toggled der Kanal nicht mehr beim Gedrückthalten so wie es der originale Aktor macht.

Code Auswählen Erweitern


  bool process (const RemoteEventMsg& msg) {
    bool lg = msg.isLong();
    Peer p(msg.peer());
    uint8_t cnt = msg.counter();
    typename BaseChannel::List3 l3 = BaseChannel::getList3(p);
    if( l3.valid() == true && cnt != messageCounter) {
  messageCounter = cnt;
      // l3.dump();
      typename BaseChannel::List3::PeerList pl = lg ? l3.lg() : l3.sh();
      // pl.dump();
      remote(pl,cnt);
      return true;
    }
else if(messageCounter == cnt) {
       return true;
}

    return false;
  }

Aktuell kann ich das Problem umgehen indem ich die Verknüpfung auf Togglen über den Counter umstelle.


Zum 3. Punkt
Könntest du das auch noch implementieren?
Damit könnte man zwei Dimmer oder Rolladen synchron per Longpress steuern.

[papa]

Ich kann auch einfach die default Initialisierung ändern und bei single-Peer bei Long einfach nichts machen - sprich lgActionType = 0.

Kannst Du mir das Problem für 3. nochmal genau beschreiben. Es sollte eigentlich keine Einschränkungen geben.

[Xent]

Meinste jetzt bezüglich des togglens?
Der originale Aktor reagiert sofort auf die erste LongPress Nachricht und man kann ihn solange gedrückt halten wie man möchte ohne dass er hin und her springt.
Nur beim nächsten LongPress reagiert er wieder.


Zu dem 3.
Also folgende Situation:
1 x Taster
2 x Dimmer
Beide Dimmer sind mit dem Taster gepairt.
Jetzt drückt man lange auf den Taster und dieser sendet das Gedrückthalten an Dimmer 1.
Nun reagiert aber nicht nur der Dimmer 1 sondern auch der Dimmer 2.
So wie es aussieht wurde dem Dimmer 2 beim Pairing mit dem Taster gesagt, dass er auf auf LongPress an Dimmer 1 reagieren soll.

Ich hab das ganze hier mal mit zwei Schaltern gemacht.

Die Schalter waren eingeschaltet und sind auf Togglen gestellt.

Code Auswählen Erweitern


Taster an Aktor 2 (Aktor 1 und 2 gehen aus)
ignore 0B 57 84 40 3B1630 442D73 46 52  - 2963261
ignore 0B 58 84 40 3B1630 442D73 46 52  - 2963528
ignore 0B 59 84 40 3B1630 442D73 46 52  - 2963795
ignore 0B 5A A0 40 3B1630 442D73 46 52  - 2964212

Taster an Aktor 1
ignore 0B 5B A0 40 3B1630 442D21 46 52  - 2964570
ignore 0E 5B 80 02 442D21 3B1630 01 01 00 00 42  - 2964697

Taster an Aktor 2
ignore 0B 5A A0 40 3B1630 442D73 46 52  - 2964868
ignore 0E 5A 80 02 442D73 3B1630 01 01 00 00 5F  - 2964996

Aktor 2 an Zentrale
ignore 0D 5B A4 10 442D73 473071 06 01 00 00  - 2966599
ignore 0A 5B 80 02 473071 442D73 00  - 2966723

Aktor 1 an Zentrale
ignore 0D 5C A4 10 442D21 473071 06 01 00 00  - 2967036
ignore 0A 5C 80 02 473071 442D21 00  - 2967160



Zum Versuch mit dem deaktivieren des Short und Long Press bei zwei Verküpfungen:
Scheinbar wird die Message nicht an den zweiten Kanal weitergeleitet wenn der erste bereits darauf reagiert.
Folgender Aufbau:
Taster 1 an Kanal 1, LONG_ACTION_TYPE --> INACTIVE
Taster 1 an Kanal 2, SHORT_ACTION_TYPE --> INACTIVE

Jetzt sollte ja Kanal 1 bei Short und Kanal 2 bei Long reagieren.
Es reagiert aber immer nur Kanal 1 bzw. macht bei Long halt nichts.

Hier mal die Messages.
Die mit Ignore gehen an einen originalen 2 Kanal Aktor.
Man sieht auch nen Unterschied bei dem ACK.

Code Auswählen Erweitern

Taster 6 an Kanal 1 Short
ignore 0B 0D A4 40 3B1630 442D73 06 42  - 1456382
ignore 0A 0D 80 02 442D73 3B1630 00  - 1456506

Taster 6 an Kanal 2 Long
ignore 0B 14 84 40 3B1630 442D73 46 45  - 1493389
ignore 0B 15 84 40 3B1630 442D73 46 45  - 1493656
ignore 0B 16 A0 40 3B1630 442D73 46 45  - 1493923
ignore 0A 16 80 02 442D73 3B1630 00  - 1494048

Taster 5 an Kanal 1 Short
-> 0B 17 A4 40 3B1630 FE3456 05 89  - 1524499
<- 0E 17 80 02 FE3456 3B1630 01 01 C8 00 51  - 1524598

Taster 5 an Kanal 2 Long
-> 0B 18 84 40 3B1630 FE3456 45 8A  - 1568027
-> 0B 19 A0 40 3B1630 FE3456 45 8A  - 1568294
<- 0E 19 80 02 FE3456 3B1630 01 01 C8 00 50  - 1568389

[Xent]

Soo, ich hab mal nen paar PullRequests erstellt.

Das Problem zu 3. habe ich nun auch verstanden wie es funktioniert.
Das bei diesen Nachrichten das Flag BCAST gesetzt ist, wird die Empfängeradresse nicht überprüft, da diese die erste ist mit dem der Taster gepairt wurde.
Wenn weitere Geräte gepairt werden, dann bleibt sie gleich.

Habe nun in MultiChannelDevice.h folgende Zeile geändert:

Code Auswählen Erweitern

if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || msg.isBroadcast() ) {
Die Funktion isBroadcast habe ich bereits im Commit für den LongPress-Fix drin allerdings hab ich sie nun direkt in die Message Klasse gepackt.
Man könnte das msg.isBroadcast noch mit ner Abfrage auf den Messagetype kombinieren (Remote und Sensor).

[papa]

Soo, ich hab mal nen paar PullRequests erstellt.

Das Problem zu 3. habe ich nun auch verstanden wie es funktioniert.
Das bei diesen Nachrichten das Flag BCAST gesetzt ist, wird die Empfängeradresse nicht überprüft, da diese die erste ist mit dem der Taster gepairt wurde.
Wenn weitere Geräte gepairt werden, dann bleibt sie gleich.

Habe nun in MultiChannelDevice.h folgende Zeile geändert:

Code Auswählen Erweitern

if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || msg.isBroadcast() ) {
Die Funktion isBroadcast habe ich bereits im Commit für den LongPress-Fix drin allerdings hab ich sie nun direkt in die Message Klasse gepackt.
Man könnte das msg.isBroadcast noch mit ner Abfrage auf den Messagetype kombinieren (Remote und Sensor).

Aha, so ganz habe ich die Logik immer noch nicht verstanden. Ich würde gern erts mal alle Kombinationen analysieren und dann den Code entsprechend anpassen.

1) 1 Taster gepeert mit 1 Switchchannel

Es wird direkt eine Nachricht an den Peer geschickt. Es ist kein BCAST gesetzt. Der Peer antwortet mit eine Ack.

1) 1 Taster gepeert mit 2 Switchchannel vom gleichen Gerät

Es wird eine Nachricht an den ersten Channel gesendet. Der zweite Channel reagiert ebenfalls auf die Nachricht. Das Gerät sendet einen Ack zurück. Was ist mit dem BCAST Flag ?

1) 1 Taster gepeert mit 2 Switchchannel vom unterschiedlichen Geräten

Es wird eine Nachricht an den ersten Peer gesendet. Zusätzlich ist das BCAST Flag gesetzt. Beide Geräte reagieren auf die Nachricht - also auch das, was gar nicht direkt adressiert ist. Wie ist es mit dem Ack ? Sende jetzt beide einen - oder nur der direkt adressierte ?


Für welche Nachrichten trifft dieses Verhalten zu ? Nur Remote-Events (0x40) oder auch Sensor-Events (0x41) ?

Wir können auf jeden Fall die isBoardcastMsg der Device-Klasse anpassen, um die entsprechenden Nachrichten zur Verarbeitung durchzulassen.

[Xent]

1) 1 Taster gepeert mit 2 Switchchannel vom gleichen Gerät

Es wird eine Nachricht an den ersten Channel gesendet. Der zweite Channel reagiert ebenfalls auf die Nachricht. Das Gerät sendet einen Ack zurück. Was ist mit dem BCAST Flag ?

Dieser Punkt hat nichts mit dem Broadcast zutun.
In Taster sendet keine Befehle direkt zu einem Channel sondern nur zum Gerät und gibt dabei an welche Taste gedrückt wurde.

Code Auswählen Erweitern

0B 15 A4 40 3B1630 46B02D 06 88
Hier jetzt der 6. Taster.

Die bisherige channelForPeer Funktion liefert aber immer nur den 1. Kanal der gepeered ist zurück.
In diesem Pullrequest https://github.com/pa-pa/AskSinPP/pull/20 habe ich das gefixt.
Wenn nur ein Kanal gepeered ist, bekommt der Sender den Status zurück.
Wenn zwei Kanäle gepeered sind, kommt nur ein ACK ohne Status zurück.



Was den Broadcast angeht, so sind dort nur die Nachrichten beim Gedrückthalten betroffen.
Beim loslassen bekommt jedes Geräte ne eigene Nachricht.
Da muss ich nochmal ran und das optimieren da das Flag noch bei mehr Nachrichten gesetzt ist.

[Xent]

Hab das ganze jetzt eigentlich genau auf die richtigen Messages eingegrenzt:

Code Auswählen Erweitern

     if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || (msg.isBroadcast() && (msg.command() & 0x40) == 0x40 && msg.type() == AS_MESSAGE_REMOTE_EVENT)) {


Somit werden die Remote_Event Messages die per Broadcast gesendet wurden und vom LongPress ausgelöst wurden weitergeleitet.
Dann prüft der Aktor ob ein Kanal gepeered ist und verarbeitet die Meldung oder macht halt garnichts, da diese Messages kein Ack benötigen.

[papa]

Nun mal langsam mit dem Code, ich versuche gerade aus Dir rauszukriegen, wie die genaue Kommunikation bei dem unterschiedlichen Fällen aussieht. Wenn wir das alles zusammen haben, gehen wir an die Implementierung.

Könntest Du bitte nochmal das Verhalten bei mehreren unterschiedlichen gepeerten Geräten bei Short- & Long-Press beschreiben. Am besten inklusive der Nachrichten der originalen Geräte.

[Xent]

Also Shortpress ist kein Problem.
Beim LongPress gibt es zwei Messages.
Einmal beim halten und eine beim Loslassen.

Die beim Halten hat die Zieladresse des ersten gepeerten Gerätes, das Broadcast-Flag und als Command Long.
Diese Nachrichten werden solange gesendet bis man den Taster loslässt.
Darauf reagieren alle mit diesem Taster gepeerten Geräte.

Beim loslassen bekommen alle gepeerten Geräte eine eigene Nachricht, dies funktioniert auch ohne Probleme.


Könnten auch mal Telefonieren oderso, geht dann vielleicht einfacher als immer hier zu schreiben