Kann gerade auch nicht testen, aber müsste passen. Mit putty lausche ich ja auch nur und bekomme die Daten.
Ankündigung
Einklappen
Keine Ankündigung bisher.
ASCII Daten über TCP empfangen und auswerten
Einklappen
X
-
Wie kann man denn mit Putty nur lauschen? Du gibst doch in Putty die IP ein und stellst die Verbindung her. Die Daten kommen dann über die Verbindung rein.
Das Binding wartet aber auf eine “incoming connection”. Also müsste der Esera Controller die Verbindung herstellen.
Wie ist denn im Esera Config Tool die Ethernet-Schnittstelle konfiguriert? Als Client oder Server?
Müsste dann “Client” sein. Oder?
Wenn das nicht geht, dreh die Rollen mal um (Binding=Client, Controller=Server).
Kommentar
-
Guter Tip! Also der Controller ist als Server eingestellt.
Hab das Item abgeändert, statt < ein > verwendet und jetzt kommen die Daten. Jetzt muss ich mal nach dem nächsten Problem mit REGEX schauen
Code:String OWinput { tcp=">[192.168.0.110:5000:'REGEX((.*))']"}
Kommentar
-
Problem gelöst, musste natürlich REGEX erst installieren
Hab jetzt auch das Item geändert, ich will ja einen Zahlenwert bekommen
Code:Number OWinput { tcp=">[192.168.0.110:5000:'REGEX(.*1_OWD1|(.*))']"}
Regex_Fehler2.JPG
Bin dran!
Kommentar
-
So, ich denke hier fehlt noch dir Transformation, ich will jetzt ja einer Number einen String zuweisen.
Ich habe jetzt gleich noch was anderes versucht, so wie udo1toni es weiter oben vorgeschlagen hat. String empfangen und in einer Rule zerlegen. Hab noch einen Log hinzugefügt weil es nicht funktioniert hat.
Items:
PHP-Code:Group gSensoren
String OWinput { tcp="<[192.168.0.110:5000:default]"}
Number OWSensor1_OWD1 "OWD1 [%d]" (gSensoren)
Number OWSensor1_OWD2 "OWD2 [%d]" (gSensoren)
PHP-Code:var String TAG = "ow.rules"
rule "OWinput auslesen"
when
Item OWinput changed
then
gSensoren.members.forEach[i|
logInfo(TAG, "durchlauf=" + i )
val String sReg = "(.*1_"+i.name.split("_").get(1)+"|(.*))"
logInfo(TAG, "string=" + sReg )
val Number nWert = transform("REGEX",sReg,OWinput.state)
logInfo(TAG, "wert=" + nWert )
i.postUpdate(nWert)
]
end
Regex_Rule_Log.JPG
Ich glaub ich versteh die Rule nicht ganz. Hätte jetzt erwartet es ist eine Zählschleife und i ein Index. Aber laut Log beinhaltet i den Namen des ersten Items der Gruppe.
Dann hatte ich im Log unter String= den Zahlenwert als String erwartet...
Naja, hatte mal wie einenhalb Stunden Zeit rumzuspielen, hat wohl nicht gereicht, vielleicht morgen wieder
Kommentar
-
Die Zeile gSensoren.members.forEach bedeutet: durchlaufe die Gruppe gSensoren Anschließend kommt ein Lambda (alles innerhalb []) welches beschreibt, was mit jedem einzelnen Member passieren soll. Innerhalb des Lambdas ist immer exakt ein Member vorhanden, das Lambda wird einfach nacheinander für alle Member ausgeführt. Dabei dient die Variable i (vor dem |) als Stellverteter, das heißt, im Lambda wird i jeweils durch das gerade bearbeitete Item ersetzt. i ist also ein Item, womit auch alle Methoden, die für ein Item zur Verfügung stehen, verwendet werden können. Das ist der Witz am objektorientierten Programmieren
Die Rule mit passendem Logging:
Code:var String TAG = "ow.rules" rule "OWinput auslesen" when Item OWinput changed then gSensoren.members.forEach[i| logInfo(TAG, "Item: {}", i.name ) val String sReg = "(.*1_"+i.name.split("_").get(1)+"|(.*))" logInfo(TAG, "sReg: {}", sReg ) logInfo(TAG, "OWinput.state: {}", OWinput.state ) val Number nWert = transform("REGEX",sReg,OWinput.state) logInfo(TAG, "nWert: {}", nWert ) i.postUpdate(nWert) ] end
Eventuell muss der senkrechte Strich | im Regex-Ausdruck escaped werden. Dann sähe die Zeile so aus:
Code:val String sReg = "(.*1_"+i.name.split("_").get(1)+"\\|(.*))"
Was mir noch etwas Sorge bereitet, ist die Tatsache, dass der Name nicht immer im OWinput-String vorkommt, stattdessen taucht ab und zu 1_KAL auf. Das müsste man dann abfangen.Zuletzt geändert von udo1toni; 13.02.2019, 00:49.
Kommentar
-
So, hab es mal mit beiden Varianten versucht, hat nicht funktioniert. Hier der Log der zweiten Variante:
Regex_Rule_Log2.JPG
Das 1_KAL dürfte doch eigentlich kein Problem sein, wir suchen ja nach 1_OWDx ?
Kommentar
-
Eventuell muss der Backslash sogar 4-fach angegeben werden:
Code:val String sReg = "(.*1_"+i.name.split("_").get(1)+"\\\\|(.*))"
Aber erst mal müssen wir die hartnäckige erste Fehlermeldung weg bekommen.
Achja... Kannst Du nach Möglichkeit keine Screenshots hochladen, sondern stattdessen die Texte als Text in die Zwischenablage kopieren und dann hier als Code posten? ist wesentlich angenehmer in der Darstellung und braucht auch viel weniger Platz.
Kommentar
-
Hab die neue Codezeile mal ausprobiert aber ohne Erfolg. Wollte dann das KAL wegbringen, hab rausgefunden, dass man das im Controller einstellen kann. Bedeutet Keep Alive, also ein Watchdog. Hab es deaktiviert, seitdem bekomm ich gar nix mehr über das TCP Binding rein. Hab die Einstellung wieder rückgängig gemacht, openHAB neugestartet usw... Kommt nix mehr. Über PuTTY kommen die Daten noch.
Keine Ahnung was da los ist. Im Log steht auch nix... Sieht alles normal aus nach dem Neustart, aber es passiert nichts.
Code:16:52:03.714 [INFO ] [mebuilder.internal.HomeBuilderServlet] - Started Home Builder at /homebuilder 16:52:03.795 [INFO ] [bpanel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel 16:52:13.160 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'knx.items' 16:52:21.406 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'ow.rules' 16:52:21.746 [INFO ] [rthome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007 16:52:22.279 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'knx.sitemap' 16:52:22.531 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'knx.things' 16:52:22.765 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'UG_Sport-knx:device:bridge:generic:UG_Sport' has been added. 16:52:22.767 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Rolladen_OG_Leo_Sued-knx:device:bridge:generic:Rolladen_OG_Leo_Sued' has been added. 16:52:22.773 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'UG_Hobby_Licht-knx:device:bridge:generic:UG_Hobby_Licht' has been added. 16:52:23.712 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.0.107:8080 16:52:23.714 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.0.107:8443 16:52:24.173 [INFO ] [marthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui 16:52:25.019 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNINITIALIZED to INITIALIZING 16:52:25.071 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from INITIALIZING to UNKNOWN 16:52:25.127 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The maximum buffer will be set to the default value of 1024 16:52:25.129 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The cron job to reset connections will be set to the default value of 0 0 0 * * ? 16:52:25.131 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The setting to queue write operation until a channel gets connected will be set to the default value of true 16:52:25.134 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The setting to share channels within an Item will be set to the default value of true 16:52:25.137 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The setting to share channels between the items with the same direction will be set to the default value of true 16:52:25.140 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - The setting to share channels between directions will be set to the default value of true 16:52:25.146 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - Listening for incoming connections on /0.0.0.0:5003 16:52:25.153 [INFO ] [ding.tcp.protocol.internal.TCPBinding] - The maximum time out for blocking write operations will be set to the default value of 3000 16:52:25.164 [INFO ] [ding.tcp.protocol.internal.TCPBinding] - The blocking nature of read/write operations will be set to the default value of false 16:52:25.175 [INFO ] [ding.tcp.protocol.internal.TCPBinding] - The preamble for all write operations will be set to the default value of "" 16:52:25.185 [INFO ] [ab.core.service.AbstractActiveService] - TCP Refresh Service has been started 16:52:25.192 [INFO ] [ding.tcp.protocol.internal.TCPBinding] - The postamble for all write operations will be set to the default value of "" 16:52:25.256 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from UNINITIALIZED to INITIALIZING 16:52:25.264 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE) 16:52:25.413 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNKNOWN to ONLINE 16:52:25.418 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE 16:52:25.459 [INFO ] [ding.tcp.AbstractSocketChannelBinding] - We will accept data coming from the remote end /192.168.0.110:5000 16:52:25.690 [INFO ] [smarthome.event.ItemStateChangedEvent] - UG_Hobby_Licht changed from NULL to ON
Der Tip mit dem Codefenster für den Log ist übrigens sehr gut, daran hab ich gar nicht gedacht
Kommentar
-
Habe heute meinen Controller bekommen und mal einen Sensor angehängt.
Mit folgender Rule klappt das Parsen der Werte ganz gut:
Code:var String TAG = "ow" rule "Read OWinput values" when Item OWinput changed then val lines = OWinput.state.toString.split("\\R+") logInfo(TAG, "There are {} lines: {}", lines.size, lines) lines.forEach[line| if (line.contains("OWD")) { val lineArray = line.split("^1_|\\|") var sensorName = lineArray.get(1) var sensorValue = lineArray.get(2) logInfo(TAG, "Sensor name: {} = {}", sensorName, sensorValue) postUpdate("OWSensor_" + sensorName, sensorValue) } ] end
Die Items sehen dann so aus:
Code:Group gSensoren String OWinput { tcp=">[192.168.0.110:5000:default]"} Number OWSensor_OWD1 "OWD1 [%d]" (gSensoren) Number OWSensor_OWD2_1 "OWD2_1 [%d]" (gSensoren) Number OWSensor_OWD2_2 "OWD2_2 [%d]" (gSensoren) Number OWSensor_OWD2_3 "OWD2_3 [%d]" (gSensoren) Number OWSensor_OWD2_4 "OWD2_4 [%d]" (gSensoren) Number OWSensor_OWD3 "OWD3 [%d]" (gSensoren)
Kommentar
-
Habe es jetzt einen Tag laufen. Bisher keine Auffälligkeit.
Leider gibt es ab und zu noch ein Problem beim Empfang der Daten, schau mal hier.
Update: Ok, was scheinbar nicht richtig geht ist der reconnect. Also wenn ich den Controller vom Strom nehme und nach einer Weile wieder starte, verbindet sich das Binding nicht wieder selbst.Zuletzt geändert von Digitalvitamin; 03.03.2019, 11:56.
Kommentar
Kommentar