Einbindung FS20-Komponenten

Baumert

Hallo, vielen Dank erst einmal für Deine Hilfe…

Am Wochenende werden ich mich noch einmal darum kümmern, ich bin ab morgen erste einmal auf Geschäftsreise.

Grüße

Thomas

Baumert

Hallo, kurz zur Info…

ich steige jetzt von FS20 auf Homematic um - finde ich sowieso besser wegen der bidirektionalen Verbindung.

Habe mir jetzt zum testen ein das Funkmodul und einen Homematic-Heizungsregler besorgt...

Kämpfe jetzt hier mit dem hm-Adaptern, dazu aber dann ein neues Thema..

Vielen Dank für die Unterstützung

dondaik

möge sich der sieg über die hardware einstellen ;-) … viel spass

Mickbaer

Hallo,

ich habe auch das Problem, das der CUL-Adapter in ioBroker nicht so recht laufen möchte.

Ich habe einen nanocul, V1.63 lauffähig von FHEM an einen neuen RPI3, mit neustestem ioBroker image,

an ttyUSB0 gesteckt, und der CUL stellt sich wie tot. ioBroker Adapter ist Grün, steht auf ttyUSB0 und

in den logs tut sich nix.

Ich habe herausgefunden, das dem CUL, das init command fehlt.

Also beim starten braucht der CUL z.B. ein "X01" zur initialisierung, damit er überhaupt beginnt zu arbeiten.

Somit habe ich per minicom auf die ttyUSB0 einen X01 gesendet, während der der ioBroker CUL adapter lief,und siehe da,

es werden Daten von meinem FS20 Funktastern empfangen.

Ich hänge mal einen Screenshot hier dran.

Ich wäre dankbar für einen Tip, wo in den Java-Scripts, die Initsequenz, die anscheinend auf "X01" steht,

aber nicht ausgeführt wird, repariert werden kann.

Gruß

Mickbaer aus Berlin
5817_cul_adapterlog.png

apollon77

Pack das bitte mak in ein GithUb Issue für den cul adapter

Mickbaer

Hallo,

bin noch neu hier, und weiß nicht wie ich das bei Github einstellen soll.

(vielleicht kann das bitte mal einer machen)

Ich bin schon ein Stück weiter,

ioBroker sendet die X21, mit 38400bd,auf ttyUSB0,

aber das reicht anscheinend nicht aus, es muss danach noch ein "return" kommen,

damit der CUL es frisst.

Den init cmd auf X21\r\n zu erweitern

(das sendet der ioBroker auch alles braf)

( habe die CUL.js etwas gepatcht) hilft nicht.

Habe jetzt leider keine Zeit, müssen wir auf später vertagen…

Vielleicht hat jemand noch eine Idee.

Gruß Mickbaer.

apollon77

Hi,

also wenn Du gerade experimentierst dann ist es cool wenn Du rausfindest was geändert werden muss. Ich persönlich hab keinen CUL zum testen.

Github easy … https://github.com ... Account erstellen, Dann unter https://github.com/ioBroker/ioBroker.cul auf "issues" gehen und dort ein Issue aufmachen :-)

Mickbaer

Hallo,

Ich habe den CUL-Adapter 0.3.0 von Github installiert.

(neuste Version)

Auch in dieser Version wird mein nanoCUL868 FW 1.63, an ttyUSB0 nicht richtig initialisiert.

Ich habe diesen Bug, fixen können, durch die Änderung der Initsequenz auf:

Buadrate: 38400

V\r\n

delay(1000ms)

X21\r\n

T01\r\n

Danach antwortet der nanoCUL868 wie gewünscht, entsprechend wie er es auch schon in FHEM gemacht hat,

auch im iobroker.

Ich hänge hier die beiden Dateien an,

/opt/iobroker/node-modules/iobroker.cul/cul.js => Datei1-cul.js

/opt/iobroker/node-modules/iobroker.cul/node-modules/cul/cul.js =>Datei2-cul.js

die ich gepatcht habe.

Mit diesen beiden, hart gepatchten dateien, kann Ich jetzt meine

FS20 S4A-2

FS20S19

Fernbedinungen auch im iobroker empfangen.

Ich hoffe die Entwickler des CUL-Adapters, können diesen Patch an den richtigen Stellen in ihren Adapter einbauen

und in der nächsten Version allen usern zur Verfügung stellen.

Gruss Mickbaer aus Berlin
5817_1.png
5817_2.png
5817_3.png
5817_datei1-cul.js
5817_datei2-cul.js

apollon77

Schaue ich mir heute Abend an.

Ist das jetzt speziell für nanocul nötig oder bei allen?!

Mickbaer

Ich habe nur den nanoCul als Nachbau und der hat an FHEM anstandslos funktioniert.

Die init-sequenz ist von FHEM, die delay die ich hinzugefügt habe, war das entscheidende.

Also gebt dem CUL etwas zeit zum Verarbeiten der Befehle,

kommen die zu schnell hinter einander, verschluckt er sich,

und versteht dann nur BAHNHOF.. was wir ja nicht wollen. :lol:

Ich kann mit meinem nanoCUL testen, wenn das gebraucht wird. :roll:

Gruß Mickbaer aus Berlin :D

Homoran

Die Baudrate ist um einiges höher sls beim busware cul, dort sind es 9600.

Kann sein, dass deswegen das delay nötig ist.

Ich würde das dann mit meinem busware cul gegentesten. Habe aber nur einen Erschütterungssensor.

Gruß Rainer

Mickbaer

Hallo,

ich hatte in dem Java code, auch ESA gesehen.

Ich Habe einen ESA2000WZ an FHEM am laufen(schon sei Jahren zuverlässig).

Mein nanoCUL868 empfängt nun auch die EsaMessages.

S7F3CF9011E000687B80004000000014B2B

S003CF9011E000687BB0003000000014B2B

S013CF9011E000687BF0004000000014B2F

S033CF9011E000687C60003000000014B2D

S053CF9011E000687CE0004000000014B2E

S853CF9011E000687CE0004000000014B2E

in der CUL-Adapter Version 0.2.0 war ESA noch drin. Bei der Vesion 0.3.0 fehlt das jetzt.

Die esa.js zeigt nur einen Rumpf,

module.exports.parse = function (raw) {

var message = {

protocol: 'ESA'

};

return message;

};

da fehlt der ganze Teil der Decodierung.

Gibt es da schon was?

Ich bräuchte den ESA2000WZ im iobroker.

Gibt es da schon was?

Wird denn an dem CUL-Adapter noch regelmässig gearbeitet?

Kann man da irgendwo unterstützen?

Gruß Mickbaer aus Berlin

apollon77

ESA war früher drin?! Das wäre komisch.

Wir benutzen die cul Library von hobbyquaker https://github.com/hobbyquaker/cul

Der Adapter kann daher alles was die Library parsen kann.

ESA steht auf Todo. Kannst anschauen wie die anderen protokollparser tun und esa implementieren. Hobbyquaker nimmt pullrequests gern an.

apollon77

~~@Mickbaer:~~

Hallo,

Ich habe den CUL-Adapter 0.3.0 von Github installiert.

(neuste Version)

Auch in dieser Version wird mein nanoCUL868 FW 1.63, an ttyUSB0 nicht richtig initialisiert.

Ich habe diesen Bug, fixen können, durch die Änderung der Initsequenz auf:

Buadrate: 38400

V\r\n

delay(1000ms)

X21\r\n

T01\r\n

Danach antwortet der nanoCUL868 wie gewünscht, entsprechend wie er es auch schon in FHEM gemacht hat,

auch im iobroker. `

Was sendet der Adapter denn wenn Du nichts änderst?

"V" gibt nur die Version aus. Sollte daher eigentlich keinerlei Auswirkungen haben. Kommt eine Versionsausgabe?

"T01" gibt den aktuell gesetzten Hauscode aus. Also auch das sollte keine Auswirkung haben.

"X21" ist damit das einzig interessante Kommando. Es sind Bits 0 und 5 gesetzt, was bedeutet:

Bit 0: Report known messages (parity & checksum ok), with type prefix.

Bit 5: RSSI: report RSSI value as an additional HEX byte after digested data or as a separate byte if Bit 3 is set too.

Der Adapter sendet X21\r\n zur Initialisierung.

Ich habe auch in Google nichts gefunden was Deine Erfahrungen "belegt" oder begründet.

Kannst Du mal verschiedene Initialisierungsvarianten (Also mal ohne das V oder ohne das T01 oder wirklich nur X21 als erstes) ausprobieren und Deine Erfahrungen zu berichten?!

~~@Mickbaer:~~

Ich hänge hier die beiden Dateien an,

/opt/iobroker/node-modules/iobroker.cul/cul.js => Datei1-cul.js

/opt/iobroker/node-modules/iobroker.cul/node-modules/cul/cul.js =>Datei2-cul.js

die ich gepatcht habe.

Mit diesen beiden, hart gepatchten dateien, kann Ich jetzt meine

FS20 S4A-2

FS20S19

Fernbedinungen auch im iobroker empfangen.

Ich hoffe die Entwickler des CUL-Adapters, können diesen Patch an den richtigen Stellen in ihren Adapter einbauen

und in der nächsten Version allen usern zur Verfügung stellen.

Gruss Mickbaer aus Berlin `
Ja sehr hart gepatcht :-)

Den einen Teil müsste man als Pullrequest in der "cul" Library einreichen. Dazu muss ich das aber verstehen weil ich nicht weiss warum Dein Stick das so braucht und andere scheinbar tun.

Die Änderung am Adaptercode selbst is unnötig weil Du per AdapterKonfig die Baudrate setzen kannst. Das muss nicht hart kodiert werden.

apollon77

Um sicherzustellen was wirklich gesendet wird habe ich das Logging in der Library geändert.

Bitte Adapter neu von Github installieren. Version bleibt gleich. Es muss lokal git installiert sein weil die cul Library direkt von meinem Fork genommen wird.

Dann gibt es mehr Logging per "info", nämlich alles was gesendet oder empfangen wird.

Bitte das Log schicken/checken.

Ich kann dann so je nach Ergebnissen weitere Versionen liefern zum testen.

Mickbaer

Hallo apollon77,

Ich habe mich über eine Woche mit der Analüse dieses Problems beschäftigen dürfen,

was ich garnicht wollte. :roll:

Denn Ich wollte den CUL-Adapter im iobroker benutzen und nicht erst großartige Fehleranalüse und reparatur betreiben.

Ich habe das Internet quer und längs gelesen, und in diesem Blog, das naheliegenste gefunden.

Mehre Besitzer eines nachbau CUL's haben ja im Netzt, genau mein Problem beschrieben.

Die Antworten die Sie erhalten haben sind teilweise Hahnebüchen, :lol:

und haben mich auch dazu gebracht, sich diesem Problem

einmal anzunehmen und eine Lösung zu presentieren. ;)

Immer wieder liest man, da Antworten von Leuten, die die Hardware garnicht haben,

und dann Sachen schreiben, die sie nicht einmal selbst testen konnten.

Sorry aber das musste mal gesagt werden. :oops:

So nun zu deinen Fragen,

Klar sendet die original version 0.2.0 und 0.3.0

am ende ein X21, welches aus mehreren Teilen für den CUL zusammengebaut wird.

Klar kann ich die Baudrate über das Menue einstellen, aber um sicher zu gehen,

es gibt da einen Haufen .js dateien, da war es sehr schwer für mich da die richtigen Stellen zu finden,

darum dieser harte Patch, damit ich mir sicher bin, was ich da mache.

Wie du aus den screen shots siehst, habe ich die Kommunikation,

mittels externem Seirellen Monitor, für beide seriellen Richtungen von und zum CUL gemonitort um das problem zu erfassen.

Noch unklar für mich ist, das im Program immer ttxAMA0 steht, die Seriellen Ausgaben aber auf ttyUSB0 gesendet werden.

Aber egal, mein CUL steckt am ttyUSB0, und braucht 38400 Bd, 8 N 1 CR LF um angesprochen zu werden.

(so wie er es von meiner laufenden Hausautomatisierung mit FHEM gewohnt ist,

und jetzt nur nach iobroker umziehen soll.)

Ob die original version, CR LF sendet, da bin ich mir nicht ganz klar geworden, zu mindestens, das X21 habe ich gesehen,

aber damit läuft der nanoCul nicht an, das sieht man daran, das beim drücken einer Taste an der Fernbedienung,

die LED nicht unregelmässig blinkt und er sich wie tot stellt.

Also die Abfolge, X21 und dann CR LF kommt zuschnell aufeinander und damit versteht der nanoCUL das Kommando nicht.

Na klar habe ich alle erdenklichen Möglichkeiten durch probiert, alles ohne Erfolg.

Die Lösung brachte dann der Trace vom FHEM system, wo es ja seit Jahren problemlos läuft.

Und siehe da, FHEM macht das mit:

38400bd

V\r\n

X21\r\n

T01\r\n

und auch damit kam der nanoCUl, aus dem CUL-Adapter gesendet nicht klar.

Er hat zwar reagiert, aber nur mit wirren Antworten.

Erst die delay, und das auch nur in dieser, ich gebe es zu, merkwürdigen Form, ich habe nichts anderes gefunden,

ich programmiere nicht täglich in JAVA-Script.

Also langer Rede, kurzer Sinn,

der nanoCul, braucht anscheinend zur ersten Initialiserung,

ein wenig mehr zeit, und somit sendet FHEM, als erstes ein V, mit \r\n und dann wird dem nanoCUL etwas zeit gegeben,

um seine Antwort zu senden.(siehe mein Screenshot mit den grünen logs.)

Wenn sich dann alles beruhigt hat, sendet FHEM, das zweite V\r\n,

um sicher zu gehen das es auch verstanden wurde.

Auch hier wieder dem nanoCUL zeit lassen, das er Antworten kann.

Erst jetzt kommt das setzen der Initialisierung

X21\r\n

und weil es hier vom nanoCUL darauf keine Antwort gibt(das ist normal)

wird das

T01\r\n

hinter her gesendet, damit durch die Antwort vom nanoCUL sicher gestelt ist, das er für weitere kommandos bereit ist.

Wenn man wollte, könnten alle Antworten des nanoCUL auch noch ausgewertet werden,

dann wüsste der CUL-Adapter auch 100% ob die kommunikation auch richtig steht.

Aber im CUL-Adapter wird nur auf einen seriellen ERROR, nicht auf die Antworten geprüft….

Erst dieser ganze Ablauf, hat zum Erfolg geführt.

Ich habe da alle Varianten durchgespielt.

Auch eine verkürzung der delay's habe ich ohne erfolg durch probiert.

Nur die diese Variante,

V\r\n

delay(1000ms)

X21\r\n

T01\r\n

hat dann den Erfolg gebracht.

(hat mich eine Woche, jeden Abend, zig Stunden gekostet) :shock:

Aber jetzt ist es schön zu sehen, wie auf dem Monitor, die empfangenen Daten durchlaufen

tA0B555155EE1

tA0B455055CE4

tAEB4720728E5

tA0B455055CE5

S243CF9011E00068D700026000000014B2C :roll:

tA0B455055CE5

S253CF9011E00068D920022000000014B2D :roll:

SA53CF9011E00068D920022000000014B2D :roll:

tAEB4720728E6

tAEB4720728E5

tA0B455055CE6

tA0B4548542E6

tAEB4720728E7

tA0B4548542E7

SA83CF9011E00068D9D0003000000014B2F :roll:

tA0B4548542E6

tAEB4720728E1

Da ich mich in den JAVA-Scripten noch nicht so gut auskenne,

hatte Ich ja angeregt, meine bescheidenen Erfahrungen,

V\r\n

delay(1000ms)

X21\r\n

T01\r\n

zur Initialisierung des nanoCUL in den CUL-Adapter zu übernehmen.

Da gibt es bestimmt Jemanden, der das an die richtigen Stellen rücken kann.

Anregung:

Es wäre doch auch möglich per MENU neben dem CUL, auch einen nanoCUL,

mit dann den entsprechneden Änderungen einzubauen.? Das stört doch dann keinen.

Das mit der neuen Version auf Github, werde ich mir ansehe, dafür ist es jetzt ein wenig zu früh am Morgen.

Ich melde mich die Tage, wenn Ich es getestet habe, dann zurück.

Gruß Mickbaer aus Berlin

apollon77

Ok, also nähern wir uns mal.Hast Du mal den Link zu dem "Blog Beitrag" den du gefunden hattest?!

Meine aktuelle Vermutung ist ggf das der Stick erstmal ein Kommando zum "aufwachen" braucht und dafür nimmt FHEM das "V" und das fällt ihm dann manchmal runter.

Auf Github ist jetzt eine Version die erstmal ein "V" sendet, die Antwort ignoriert und 1s wartet. Dann sendet Sie das X21 als Init.

Teste bitte mal ob es damit schon tut? Wenn nein bauen wir weiter bis es geht. :-)

Ich möchte mich gern dem Minimum nötigen nähern.

Mickbaer

~~@apollon77:~~

Ok, also nähern wir uns mal.Hast Du mal den Link zu dem "Blog Beitrag" den du gefunden hattest?!

Meine aktuelle Vermutung ist ggf das der Stick erstmal ein Kommando zum "aufwachen" braucht und dafür nimmt FHEM das "V" und das fällt ihm dann manchmal runter.

Auf Github ist jetzt eine Version die erstmal ein "V" sendet, die Antwort ignoriert und 1s wartet. Dann sendet Sie das X21 als Init.

Teste bitte mal ob es damit schon tut? Wenn nein bauen wir weiter bis es geht. :-)

Ich möchte mich gern dem Minimum nötigen nähern. `
Hallo,

sorry für die Verzögerung, aber Ich bin erst jetzt dazu gekommen hier weiter zu machen.

wenn Ich die Version 0.3.0 von Github lade dann hat sich da nix geändert, es sendet wie bisher nur X21, von V ist da nix zu sehen.

wenn ich dies versuche zu laden, https://github.com/ioBroker/ioBroker.cu … 961fd64f6f

dann gibt es nur Fehlermeldungen. Siehe angehängtem Bild.

Bitte gib die Github adresse an wo ich deine geforcte version runterladen kann.

Danke und Gruß Mickbaer
5817_cul-adapter-not_loadable.png

Mickbaer

Nachtrag,

bin gerade auf diesen Beitrag > maxcul ist komplett unbrauchbar (geloest) gestolpert.

Da ist ja auch an einer Stelle ein Bezug zu diesem Beitrag drin.

Das was der MAX-Cul da zur Intialiesrung braucht, ist für den nanoCul auch wichtig.

Sollte bitte auch eingebaut werden. :roll:

38400bd, 8 n1,

und zu Beginn das V\r\n senden zur Initialisierung,

dann auf die Antwort warten und auswerten, heißt den epfangenen String lesen bis \r da war.

Erst dann steht die Kommunikation.

Ich hoffe das hilft den CUL-Adapter jetzt zu reparieren.

und auf einen neue Version 0.3.1 hoch zu ziehen, damit man auch sicher ist, das wir über die richtige Version reden.

Gruß Mickbaer aus Berlin

apollon77

Hi,

maxcul hatte andere probleme als cul …

Bitte URL https://github.com/ioBroker/ioBroker.cul/ für custom-install nutzen.Dann müsste die 0.3.0 kommen

Community Forum

NEWS

Einbindung FS20-Komponenten

Support us

642

32.4k

81.6k

1.3m