Mysensors - Wrong UDP data recieved from 192.168.1.102:57213: 234567890
-
Ich möchte ekey Fingerprintleser über iobroker (raspi 3) mit homematic Türschlossantrieb über das ekey UDP Gateway ( https://www.ekey.net/assets/media_cente … _RS485.pdf ) verbinden.
Zur Vorbereitung (Vorabtest) habe ich den mysensors Adapter installiert, auf Server Mode UDP mit der IP-Adresse des Raspi eingestellt und an seine IP-Adresse von der Windows-SW Software "Packet Sender" den UDP- Datenstring "234567890" gersendet.
Ich habe im Adapter Inclusion aktiv und auch vor dem Senden den Anlern-Modus aktiviert.
Der Datenstring kommt im iobroker an, wird dann allerdings nur im Log als Warnung eingetragen.
Es ist mir bislang nicht gelungen, diesen Wert in einer iobroker Variablen zu empfangen.
Wer kann helfen?
PS: Gibt es ein mysensors Adapter spezifisches Handbuch, das die Parametrierung der Objekte (insbesondere bezogen auf UDP mode) und die Bedeutung von Inclusion und Anlern-Modus genauer beschreibt?
Logfile:
mysensors.0 2018-01-26 11:08:36.906 warn Wrong UDP data received from 192.168.1.102:57213: 234567890
mysensors.0 2018-01-26 11:08:22.146 warn Wrong UDP data received from 192.168.1.102:57213: 234567890
mysensors.0 2018-01-26 11:08:21.213 debug Sent to 192.168.1.102 0;0;3;0;13;force restart
mysensors.0 2018-01-26 11:08:21.212 debug Send raw data: 0;0;3;0;13;force restart
mysensors.0 2018-01-26 11:08:19.714 debug Sent to 192.168.1.102 0;0;3;0;19;force presentation
mysensors.0 2018-01-26 11:08:19.713 debug Sent to 192.168.1.102 0;0;3;0;6;get metric
mysensors.0 2018-01-26 11:08:19.712 warn Wrong UDP data received from 192.168.1.102:57213: 234567890
mysensors.0 2018-01-26 11:08:19.709 debug Send raw data: 0;0;3;0;19;force presentation
mysensors.0 2018-01-26 11:08:19.708 debug Send raw data: 0;0;3;0;6;get metric
mysensors.0 2018-01-26 11:08:19.705 info Connected 192.168.1.102:57213
mysensors.0 2018-01-26 11:08:11.928 debug stateChange mysensors.0.inclusionOn {"val":false,"ack":false,"ts":1516961291923,"q":0,"from":"system.adapter.admin.0","lc":1516961291923}
mysensors.0 2018-01-26 11:08:09.407 debug sendTo "listUart" to system.adapter.admin.0 from system.adapter.mysensors.0
mysensors.0 2018-01-26 11:08:09.399 info List of port: [{"comName":"/dev/ttyAMA0"}]
mysensors.0 2018-01-26 11:07:52.713 debug stateChange mysensors.0.inclusionOn {"val":true,"ack":false,"ts":1516961272708,"q":0,"from":"system.adapter.admin.0","lc":1516961272708}
mysensors.0 2018-01-26 11:07:45.363 debug stateChange mysensors.0.inclusionOn {"val":false,"ack":false,"ts":1516961265358,"q":0,"from":"system.adapter.admin.0","lc":1516960267608}
mysensors.0 2018-01-26 11:07:33.822 debug stateChange mysensors.0.inclusionOn {"val":false,"ack":false,"ts":1516961253817,"q":0,"from":"system.adapter.admin.0","lc":1516960267608}
mysensors.0 2018-01-26 11:06:55.078 debug sendTo "listUart" to system.adapter.admin.0 from system.adapter.mysensors.0
mysensors.0 2018-01-26 11:06:55.050 info List of port: [{"comName":"/dev/ttyAMA0"}]
-
Ich habe nicht viel Ahnung von mysensors, aber mit dem was ich bisher gesehen hab ich ein Datenstring von " "234567890" nicht in einem mysensors format …
-
@apollon77: Danke für die schnelle Antwort
In dem ekey Gateway Handbuch S. 8-11 werden die Datenformate für den erforderlichen UDP-Datentransfer beschrieben. Neben Stringdaten werden auch long Datenfelder übertragen.
So gesehen ist mein Stringfeld (für einen Anfangstest) trivial.
Ich hoffe doch, dass die UDP Implementation im mysensors Adapter bei den Datentypen keine nennenswerten Limitationen ausweist. 1024 bytes und alle gängigen Feldtypen sollten schon gehen, oder?
Hinzu kommt ja noch, dass die empfangenen Daten erst in einem Script ausgewertet werden müssen, um dann homematic keymatic Funktionalitäten aufzurufen. Also ist erste Empfangsinstanz für die Variablen ein Script und kein Gerät.
Aber konkrete Rückfrage: Was wäre denn ein korrektes mysensors Format?
-
Ist das UDP von deinem ekay Gateway wirklich mysensors kompatibel? Wenn ich das Handbuch lese isteht da nirgends etwas von "Mysensors" als protokoll.
Daher nehme ich an es sind eigene UDP-Formate. Da bringt Dir der mysensors Adaoter pot. nichts oder wie kamst Du drauf das das gehen könnte?
Wenn Du einfach nur UDP kommunikation willst wirst DU wohl bei einem eigenen Javascript landen
-
IMO gibt es keine ekey Einbindung in mysensors. Somit ist das Datenformat erstmal nicht identisch mit einem anderen bislang über UDP integrierbaren (bekannten) Gerät.
Wenn in mysensors UDP Datenempfang möglich ist, wie erfahre ich dann, welche Geräte mit welchem Datenformat über UDP Daten senden?
Wenn schon der (sehr gute Ansatz) zur Unterstützung von UDP gewählt wurde, warum soll dann nicht ein Raw-Datenfeld als Datentyp bereit gestellt werden können?
Nach meinem Verständnis würde das bedeuten, dass erst ein Gerät am Markt existieren muss und dann für dieses Gerät ein Adapter gebaut werden muss.
Da wäre ein weiterer Datentyp raw/bytearray o.ä. doch eine sehr viel flexiblere Lösung, neue Geräte einzubinden.
Falls ein neues Scipt für eine Integration gebaut werden muss, wie erfahre ich dann, wo und wie die Raw-Daten in iobroker ankommen? Schließlich landen sie ja auch intakt im Log.
-
Der "mysensors" Adapter ist dafür da mit mysensors Geräten zu kommunizieren. Auf der Infoseite zum Adapter unter https://github.com/ioBroker/ioBroker.my … rmysensors steht was der Adapter tut und link zur mysensors-Seite unter https://www.mysensors.org/ ... MySensors ist eher für "eigene Geräte" gedacht. Der Adapter kann das weil es die mysensors-Bibliothek als einen erlaubtem Übertragungsweg erlaubt. An der Stelle macht der mysensors-Adapter genau das was er tun soll: MySensors Kommunikation
Den Adapter zusätzlich zweckzuentfremden für Dinge die nicht "Mysensors" ist macht es intransparent und würde keiner erwarten.
Einen "ohne spezifisches protokoll und so UDP Daten empfangen"-Adapter gibt es in ioBroker nicht. Ich denke auch weil der Mehrwert sich eher in grenzen hält und auch weil es in einem eigenen Skript im JavaScript Adapter mit wenigen zeilen zu erledigen ist.
Referenz: https://nodejs.org/api/dgram.html
Adapter sind üblicherweise dazu da um komplexere und umfangreichere Dinge bei der Kommunikation, protokollen und so so zu erleichtern das man sich damit nicht beschäftigen muss.
-
… dieser Satz lässt mein Herz gleich höher schlagen: "... weil es in einem eigenen Skript im JavaScript Adapter mit wenigen zeilen zu erledigen ist."
Dann muss ich wohl in den sauren Apfel beißen und ein eigenes Script dafür erstellen ...
-
Der Mehraufwand wird das Parsen der Datens ein :-))
-
Kann mir jemand für den Einstieg zur Erstellung eines Javascripts zum UDP Empfang ein paar Hinweise geben oder ein Code-Snippet?
Kann ich das mit Blocky realisieren? Bei den Standard-Aktionen unter Blocky bin ich nicht fündig geworden.
Nach meinem Verständnis läuft der UDP server nach dem Start von iobroker permanent und ich muss unter localhost:portnummer abfragen, ob ein Datenpaket angekommen ist.
-
Hilfreich wäre, wenn mir jemand sagen kann, welche UDP bezogenen Funkionen im iobroker definiert sind und wo ich die doku dafür finde.
-
Um ekey einzubinden würde der Empfang eines Strings in der Art "19999R123456789ABCDE19" ausreichen.
-
Nun bin ich schon viel weiter
Ein paar Fragen hab ich aber noch:
1. warum benötige ich ein delay, bis ein Datenpunktwert genutzt werden kann?
2. warum ist bei setState string Variablenübergabe ein Leerstring vor der Variablen notwendig? Ansonsten wird ein Leerstring im state gespeichert.
3. Muss der createState 'UDP_val' in iobroker nur einmal ausgeführt werden und bleibt er in iobroker auch über Stopp und Neustart hinaus erhalten?
4. Wie ändere ich einen JavaScript Namen?
JavaScript Code:
/*
UDB value empfangen und in variable laden
teststring home protokoll:
19999R123456789ABCDE19
function createString(name) {
createState(name, "", {read: true,
write: true,
desc: "Beschreibung",
type: "string",
def: ""
});
}
*/
var lfd=0;
var PORT1 = 5003;
var HOST = '192.168.1.102';
var dgram = require('dgram');
var server = dgram.createSocket('udp4');
server.on('listening', function () {
var address = server.address();
/*createState('UDB_val',"", {read:true,
write: true,
desc: "UDB_string",
type: "string",
def: "start"
});*/
setState('UDB_val','');
setTimeout(function() { // delay, damit state gesetzt ist vor weiterer verwendung
console.log('UDP broker listening on ' + address.address + ":" + address.port + ' UDB_val: ' + getState('UDB_val').val);
}, 500);
});
server.on('message', function (message, remote) {
setState('UDB_val',''+ message,true); // warum leerstring vor der variablen notwendig?
setTimeout(function() { // delay, damit state gesetzt ist vor weiterer verwendung
lfd=lfd+1;
console.log('lfd: ' + lfd + ' UDP_val: ' + getState('UDB_val').val);
}, 500);
});
server.bind(PORT1, HOST);
