Ring Keypad Gen. 2 - kein Template vorhanden

Begonnen von Aredon, 23 November 2021, 15:16:18

Vorheriges Thema - Nächstes Thema

Aredon

Hallo,

Soeben habe ich mein Keypad (Version 2) von Ring (https://aws1.discourse-cdn.com/smartthings/original/3X/b/a/ba0b0428ef913bc7d5625859694a67429ae556f8.jpeg) erhalten, ich konnte es auch mittels FHEM pairen, allerdings steht bei STATE der Wert ???.

Ich denke, dass da auch somit keine Daten empfangen und gesendet werden können. Wenn ich irgendwelche Tasten auf dem Keypad drücke kommt im Logfile von FHEM auch nichts an.
In FHEM steht ganz oben attrTemplate und zur auswahl ?.

Ich nehme an es gibt noch kein Template dafür in FHEM? Ich finde auch leider nicht wirklich etwas im Internet darüber, so ein fertiges Template von diesem Gerät laden zu können. Allerdings hätte ich das Handbuch für den Vorgänger, der theoretisch ähnlich vom Funktionsaufbau sein soll, worin eine Befehle stehen: https://support.ring.com/hc/de/article_attachments/360051851012/Keypad_Zwave_UK.pdf

Hat jemand eine Lösung schon dafür gefunden?

Beta-User

Hallo zurück,

:) du bist der erste, der als erstes mal nach einem attrTemplate für ZWave fragt, was mich zum Teil ziemlich erfreut.

Allerdings ist bei ZWave attrTemplate kein "Selbstläufer", es gibt leider noch nicht besonders viele, und manche erfordern auch, dass vorher einiges "richtig" gemacht wurde.

Üblicherweise muss man bei neueren Geräten erst mal die "Lifeline" mit dem Controller assoziieren, damit der überhaupt Nachrichten bekommt. Hier kommt dann noch dazu, dass du da ein "Sicherheits-Gerät" hast. Bei diesem würde ich darauf tippen, dass man die meisten Infos erst dann sieht, wenn man "secure inclusion" durchgeführt hat.
Zumindest wenn das mit dem Assoziieren nicht richtig gehen will, würde ich also erst nochmal excludieren und dann mit secure inclusion nochmal starten.

Künftig bitte auch keine Screenshots einstellen, sondern "text" in Code-Tags (#-Button), dabei bitte den angepinnten Beitrag mit "was soll ich bei ZWave liefern" beachten...

Wenn wir dann wissen, wie man mit dem Ding in FHEM umgehen muss, können wir gerne ein attrTemplate daraus basteln :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatIch denke, dass da auch somit keine Daten empfangen und gesendet werden können.
Das im STATE ??? steht ist "nur" ein Zeichen dafuer, dass das ZWave Modul nicht weiss, welche der Readings sinnvoll waere.
Der Benutzer kann mit stateFormat nachhelfen. Dass Daten empfangen und gesendet wurden, sieht man am transmit und timeToAck.

Dass keine "sinnvollen" Readings vorhanden sind, liegt vermutlich daran, dass das Geraet ohne Verschluesselung inkludiert ist.

Aredon

Danke euch beiden für die raschen Antworten  :)

Was ich nun durch eure Hilfe gemacht habe:

1. das Gerät nochmals exkludiert
2. das Perl modul Rijndael installiert
3. dem ZWaveDongle den networkKey hinzugefügt
4. FHEM neugestartet
5. den Dongle auf Gerätesuche angestellt, diesmal mit onSec

Nun habe ich allerdings gleich einiges mehr an Daten und readings!

Scheinbar fehlt FHEM noch etwas zu verarbeiten einiger Daten, da im LogFile nun nach der Codeeingabe von 1234 folgendes steht:
UNPARSED: ENTRY_CONTROL 0a6f010102020431323334

Wie lässt sich das fixen?

rudolfkoenig

ZitatWie lässt sich das fixen?
Indem man das Dekodieren implementiert.
Du bist offensichtlich der Erste, der FHEM verwendet, und sich wegen einem nicht dekodierten ENTRY_CONTROL Nachricht meldet.

HOWTO:
- suchen nach ZWave SDS ENTRY CONTROL SDS
- pdf oeffnen, Kapitel mit entry control lesen
- im ZWave.pm den ENTRY_CONTROL Eintrag erweitern mit
parse => { "^..6f01(.*)" => 'ZWave_entryControlParse($hash,$1)'} },
- die o.g. Funktion implementieren und dokumentieren
- mir die Patches schicken.

Ich habe das mal vorexerziert, das o.g. UNPARSED event sollte jetzt als
entry_control: sequence 01 dataType ASCII eventType ENTER data 1234
gemeldet werden.

Aredon

Zitat von: rudolfkoenig am 23 November 2021, 18:13:32
Indem man das Dekodieren implementiert.
Du bist offensichtlich der Erste, der FHEM verwendet, und sich wegen einem nicht dekodierten ENTRY_CONTROL Nachricht meldet.

HOWTO:
- suchen nach ZWave SDS ENTRY CONTROL SDS
- pdf oeffnen, Kapitel mit entry control lesen
- im ZWave.pm den ENTRY_CONTROL Eintrag erweitern mit
parse => { "^..6f01(.*)" => 'ZWave_entryControlParse($hash,$1)'} },
- die o.g. Funktion implementieren und dokumentieren
- mir die Patches schicken.

Ich habe das mal vorexerziert, das o.g. UNPARSED event sollte jetzt als
entry_control: sequence 01 dataType ASCII eventType ENTER data 1234
gemeldet werden.

So gut kenn ich mich dann nicht mit ZWave und fhem aus, damit ich weiß, wo ich was suchen soll. Scheinbar benötigt das Keypad noch ein Setup, denn nach erstmaliger Codeeingabe wird kein weiterer Code mehr übertragen. Ist es möglich, die Signale oder Befehle die vom Keypad gesendet werden, auszulesen?

rudolfkoenig

ZitatSo gut kenn ich mich dann nicht mit ZWave und fhem aus, damit ich weiß, wo ich was suchen soll.
Deswegen habe ich das HOWTO geschrieben.
Ich kenne auch nicht alle ZWave Klassen auswendig, ENTRY_CONTROL habe ich jetzt zum ersten mal wahrgenommen.

ZitatIst es möglich, die Signale oder Befehle die vom Keypad gesendet werden, auszulesen?
Das Modul zeigt alle empfangenen Daten an, hoechstens nicht dekodiert als UNPARSED Reading.
Mit "attr device verbose 5" sieht man die kompletten Rohdaten und auch die Kontrollmeldungen.
Rohdaten senden kann man mit "get zwdongle raw ...", dazu ist aber ein bisschen "ZWave-Syntax" Verstaendnis notwendig.

Aredon

Verstehe.

Leider finde ich die Datei ZWave.pm nicht auf dem Raspberry im FHEM Verzeichnis. Mittlerweile weiß ich, wie ich die Konfigurationsbefehle senden kann: set <device> configByte xxx
Weiter komme ich nicht, wo soll denn diese Datei sein und in der ZWave Dokumentation finde ich jetzt auch nichts relevantes an Befehlen oder Informationen, die weiterhelfen könnten, echt schade  ???

Esjay

Die Datei heißt eigentlich 10_Zwave.pm

Hier mal der Blick ins svn, bzw. findest du die Datei auf deinem Raspi unter opt/fhem/FHEM/10_ZWave.pm
https://svn.fhem.de/fhem/trunk/fhem/FHEM/10_ZWave.pm

Hier kannst du dir nun den von Rudi angepassten Teil heraussuchen, und darauf aufbauen.

ENTRY_CONTROL            => { id => '6f',
    parse => { "^..6f01(.*)" => 'ZWave_entryControlParse($hash,$1)'} },
  CONFIGURATION            => { id => '70',


Grüße


rudolfkoenig

ZitatMittlerweile weiß ich, wie ich die Konfigurationsbefehle senden kann: set <device> configByte xxx
Bin unsicher, ob das ein Vertipper war, oder als ironisch zu werten ist. Die richtige Syntax ist "set <device> configByte x y"

Wenn schon das Finden einer Datei Probleme verursacht, dass sollte man vmtl. die Implementierung Anderen ueberlassen.
Aber Doku (siehe HOWTO oben) kann man auch ohne Programmierkenntnisse lesen, und es dem Programmierer "vorkauen".
Das Verstehen der Doku ist fuer mich die aufwendigere Teil der Arbeit.

Aredon

Zitat von: rudolfkoenig am 26 November 2021, 09:30:00
sollte man vmtl. die Implementierung Anderen ueberlassen.

Diesbezüglich hatte ich ja gleich im Thread gefragt ob es ein Template dafür schon gibt. Kannst du soetwas denn erstellen?

rudolfkoenig

Mit einem Template ist das Problem nicht geloest: die FHEM attrTemplates setzen "nur" implementierte Attribute. Damit kann man bei Protokollen wie MQTT ueber Regexps zwar fast alles erledigen, bei ZWave muss man aber fuer "unbekannte" Klassen Bitfriemelei betreiben, und das macht man am besten direkt im Code.

Die angesprochene Implementierung sollte im ZWave Modul erfolgen, und ja, ich kann sowas, etwa 80% des Moduls stammt von mir.
Ist halt Arbeit, und ich motiviere gerne zu Mitarbeit. Z.Bsp gilt fuers Lesen der Spec die altbeliebte Ausrede (ich kann nicht programmieren) nicht.

Aredon

Habe nun die Datei gefunden und den Code wie beschrieben angepasst. In den LogFiles steht jedoch jetzt garnichts mehr vom Gerät, dass irgendwelche daten Übertragen wurden. Oder ist dann die Ausgabe woanders, kann ich mir jedoch nicht vorstellen.

Esjay

Teil doch mal deine Ergebnisse, dann kann man zusammen drauf schauen.

Grüße