AskSin++ Library

[Xent]

Ist es eigentlich auch möglich, dass ein Schaltaktor z.B. HM-LC-SW1-SM auch den aktuellen Schaltzustand senden kann?
Die Homematic-Originale haben ja meistens noch Taster zum lokalen Schalten.

[papa]

Ist es eigentlich auch möglich, dass ein Schaltaktor z.B. HM-LC-SW1-SM auch den aktuellen Schaltzustand senden kann?
Die Homematic-Originale haben ja meistens noch Taster zum lokalen Schalten.

Das macht er doch.

Die Implementierung der Library sendet bei jedem Umschalten den Status. Außerdem kann der aktuelle Status mit einen StatusRequest abgefragt werden. Lokal mit eine Taster kann auch geschalten werden. Im Beispiel HM-LC-SWX-SM wird bei einem kurzen Druck auf den Config-Taster der erste Kanal umgeschalten.

[Xent]

Ah, super.
Den Configtaster hatte ich mir nicht so genau angeschaut.
Ich denke ich werd den Sketch des Aktors anpassen so dass man alle Kanäle direkt mit einem Eingang schalten kann und dann wieder commiten.

[papa]

Ah, super.
Den Configtaster hatte ich mir nicht so genau angeschaut.
Ich denke ich werd den Sketch des Aktors anpassen so dass man alle Kanäle direkt mit einem Eingang schalten kann und dann wieder commiten.

Bitte nicht commiten. Die Beispiele würde ich gern unter meiner Kontrolle behalten Die brauche ich auch, um Änderungen an der Library zu prüfen. Außerdem ist das der Code für die Relay-Platine von Spezialtrick.
Vielleicht macht man ja noch ein Application Verzeichnis mit fertigen Anwendungen. Da sollte dann auch immer ein Schaltplan mit rein, da nicht jeder die Schaltung direkt aus dem Code ablesen kann. Was haltet ihr davon ?

[MBHG]

Habe eben den AES Code eingecheckt. Die Beispiele sind alle entsprechend angepasst. Getestet habe ich hauptsächlich mit dem HM-LC-SWX-SM Code.

AES wird mit "#define USE_AES" aktiviert. Es sind dann auch der Key und der Index zu definieren. Doku werde ich die Tage im Readme ergänzen.

Super, freut mich. Werde es die nächsten Tage einmal ausprobieren. Das ganze läuft schon seit Monaten stabil.

Gruss Marc

[Xent]

Du hättest ja immer noch die Kontrolle, kann ja nur Pullrequests erstellen

Ich finde, dass das ruhig ins Example rein kann, solange es das Example näher ans Verhalten des originalen Aktors etc. bringt.
Das mit den Schaltplänen usw. finde ich super.
Auch ne kurze Beschreibung im Verzeichniss des Examples währe toll.
Also was man im Sketch einstellen kann z.B. die Anzahl der Relais oder aber die LowActive-Funktion usw.

[papa]

Du hättest ja immer noch die Kontrolle, kann ja nur Pullrequests erstellen

Aber ich muss mich trotzdem drum kümmern. Also Review, Nachfragen, Einpflegen ...
Das geht dann alles von meiner eh schon recht knappen Zeit ab

Ich finde, dass das ruhig ins Example rein kann, solange es das Example näher ans Verhalten des originalen Aktors etc. bringt.
Das mit den Schaltplänen usw. finde ich super.
Auch ne kurze Beschreibung im Verzeichniss des Examples währe toll.
Also was man im Sketch einstellen kann z.B. die Anzahl der Relais oder aber die LowActive-Funktion usw.

Das ist aber nicht der Code für den originalen Aktor - sondern hierfür https://forum.fhem.de/index.php/topic,48235.0.html

Wie wäre ein extra Devices-Repository. Da könnten dann auch andere direkt einchecken und weitere, richtige Geräte zur Verfügung stellen.

[Xent]

Ja das mit der Zeit kenn ich

Dass es für den Sketch auch schon die passende Platine gibt wusste ich nicht.
Ich setze bisher direkt Homematic ein und bin nur wenig hie rim Forum unterwegs.

Es soll ja nicht für den originalen Aktor sein, sondern für einen Nachbau.
Nur währ es ganz praktisch, wenn man mit dem Nachbau auch alle Funktionen wie vom Original nutzen kann .
Also auch lokal schalten.

Eigentlich ist es ganz praktisch, dass du die Examples zum testen nimmst.
Dadurch funktionieren sie immer mit der aktuellen Version bzw. man hat einen gemeinsamen Stand wenn die aktuelle Version der Lib gerade nicht tut.
Das ist mir beim NewAskSin aufgefallen, da gibt es zwar auch Beispiele aber die lassen sich nicht mehr compilen weil die Lib umgebaut wurde.

[Xent]

Mal was anderes.
Hat es schon wer hinbekommen ein Gerät mit AskSin++ mit der originalen CCU mit AES zu pairen?

Hab jetzt schon diverse Kombinationen aus Key und KeyIndex versucht.
In der Datei /etc/config/keys stehen ja die Keys drin, wie bei FHEM.
Bei mir sind es 3 und der 3. entspricht auch dem MD5 Hash meines Sicherheitsschlüssels.
Hab jetzt als Index schon 3 und 6 versucht aber das bringt nichts.
Die CCU fragt mich dann nach dem Sicherheitsschlüssel aber auch wenn ich den eingebe funktionierts nicht.

Vielleicht hab ich dadurch auch noch nen Bug gefunden.
Manchmal nach dem 2. Pairingversuch blingt die LED von vom Arduino nur noch wild.
Auch der Resettaster bringt nichts.
Ich muss den Arduino vom Strom trennen damit der sich wieder fängt.
Die letzte Ausgabe ist immer "<- 1A 02 A0 00 78 90 1".

[papa]

Ich habe kein CCU - teste aber mit HM-UART, HM-CFG-USB und CUL (umgeflashter Cube).

Welchen Branch benutzt Du ?
Bitte mal die gesamten Ausgaben der Console posten.

Möglicherweise muss der HM-Standard-Key eincompiliert werden, da ja die CCU bei einem neuen Geräte davon ausgeht, dass es noch den originalen Key hat. Beim Übertragen des "aktuellen" Keys wird dieser dann aber mit dem Standard-Key verschlüsselt - das geht bei einem eigenen Key natürlich nicht.

Den Standard-Key findet man mit Google. Ich habe ihn nicht im Code, da ich nicht weiss, ob ich durch dessen Veröffentlichung gegen irgendwelche Gesetzte verstoße. Das "Knacken" von Verschlüsselung ist ja heutzutage schlimmer als Mord.

[Xent]

Ach mist.
Hatte vergessen, dass die Lib ja im Verzeichniss von der Arduino IDE auch aktualisiert werden muss.
Hatte vorher irgendwas von Anfang des Jahres noch vor dem V1.
Bin jetzt auf V1.
Es reicht wenn man den originalen Homematic Key einträgt und KeyIndex 0 lässt.

Ich denke die Suchworte für Google darf man auf jedenfall posten ansonsten bitte entfernen:

"pastebin homematic"
Direkt der erste Treffer.

[xkalle01]

Hallo papa und Dietmar,

Ich lese diesen Threat schon einige Zeit und habe meinen Universalsensor Nachbau mit einem BME280 mit der AskSinPP am Laufen.
Läuft alles soweit prima.

Seit letztem Wochenende läuft auch mein MotionDetector mit der gleichen Platiene des Universalsensor Nachbaus.
Wenn interesse besteht, poste ich gern den Schaltplan.

Mit Interesse habe ich gesehen, dass Dietmar an den Registern arbeitet.
Besonders die List0 währe interessant, dort sind viele Konfigurationen enthalten, die ich gern über FHEM setzten würde.
Oder geht das schon und ich habe es nur noch nicht verstanden?

Viele Grüße
Kalle

[Dietmar63]

Ich habe ein Perlscript(+Linuxscipte) angepasst, das aus einer XML-Beschreibung der CCU heraus  die ListKlassen und MessageKlassen für AskSin++ generieren kann(Betaphase).
Da die Universalsensorbeschreibung  vermutlich nicht als XML vorliegt, wird es schwierig sein, da etwas zu generieren.

Beim MotionDetector sollte es aber problemlos möglich sein da etwas zu generieren, wobei ich Stirng-Getter/-Setter zunächst mal generiere, sie aber nicht übersetzbar sind(löschen oder von Hand anpassen). Das will ich in einer späteren Version anpassen. Inwiefern die Register dann zwischen CCU/FHEM und den Sensoren auch korrekt ausgetauscht werden, kann ich nicht sagen, weil ich mich damit nicht beschäftigt habe. Das erledigen die Klassen von papa.

Wenn du willst, kann ich dir den Code generieren. Du musst mir nur sagen welches Gerät(Code) du benötigst.

Die Versionen liegen im Moment bei papa.
Er prüft, ob er sie auch unter Windows zum Laufen bekommt. Wenn es klappt, wird er sie in git einchecken.

Hast du mal eine Messung des Stromverbrauchs durchgeführt?

Einen MotionDetector(auf Basis proMini 3,3V + HC-SR501)  habe ich auch in Arbeit, auch er läuft von der Software her soweit. Ich will den Stromverbrauch(zur Zeit 0,070mA) noch soweit herunterdrücken, dass 2-3 AA(A) Batterien  möglichst lange halten. Ich schätze, dass ich nochmals ca. 0,045 mA einspare, wenn ich den LOD herauslöte.

Dietmar

[xkalle01]

Hallo Dietmar,

danke für die schnelle Antwort.

Model für den Universalsensor: 0xF1, 0x01
Subtyp:  0x70.
Dafür gibt es wohl keine XML-Definition (oder?).

Die Klassendefinition für den Universalsensor ist jedoch schnell heruntergeschrieben, nur ist die List0 nicht als Parameter an der Channel Definition zu übergeben.
Das ist wohl eine Änderung in der AkSin++ Lib selbst.

Für den MotionDetector ist es der Type, den papa in seinem Beispiel verwendet.
Model: 0x00,0x4a
SubTyp: 0x81

Ich habe noch keine Strommessung durchgeführt, kann ich aber in den nächsten Tagen einmal machen.
Ich betreibe meinen MotionDetector mit 2xAA, mal sehen wie lange der läuft

[Dietmar63]

Model für den Universalsensor: 0xF1, 0x01
Subtyp:  0x70.
Dafür gibt es wohl keine XML-Definition (oder?).

leider: F101 ist homebrew

Die Klassendefinition für den Universalsensor ist jedoch schnell heruntergeschrieben, nur ist die List0 nicht als Parameter an der Channel Definition zu übergeben.
Das ist wohl eine Änderung in der AkSin++ Lib selbst.

vielleicht gibt es keine Einstellungen, die ausgetauscht werden können. Ich habe alles fest programmiert.

Für den MotionDetector ist es der Type, den papa in seinem Beispiel verwendet.
Model: 0x00,0x4a
SubTyp: 0x81

dafür liefere ich dir mal die generierten Klassen, dann kannst du prüfen, ob noch etwas umgebaut werden sollte.

Ich habe noch keine Strommessung durchgeführt, kann ich aber in den nächsten Tagen einmal machen.
Ich betreibe meinen MotionDetector mit 2xAA, mal sehen wie lange der läuft

Wenn du auch den hc-sr501 verwendest, dann läuft der vielleicht nur bis 3,0V stabil - so steht es jedenfalls im Datenblatt.
Ich überlege, ob ich auf LiPos(ausgediente HandyAkkus 3,5-4,2V) gehe oder 3xAA nehme. 3xAA sollten die bessere Wahl sein - nehmen aber auch gut Platz ein.