IP-Telegramme senden/empfangen TCP - nur eine Session

[knxhans]

Da das Thema TCP mit dem HS absolutes Neuland ist hoffe ich, dass mich hier keiner auslacht :-)

Ich habe meinen Husquvarna Automower ein WLAN Modul verpasst. Zum steuern gibt es ein Programm - das funktioniert, nützt mir für den HS aber nix.

Ich habe ebenso ein Python Skript erhalten und einige Befehle. Dateien siehe Anhang.

Ich muß per TCP um den Status abzufragen einen 5 Byte Wert senden, z.B.:

für
READ STATUS 0F01F10000
READ CHARGING TIME M 0F01EC0000
READ MOWING TIME M 0F00560000
READ OPERATING HOURS 0F46980000

Dann bekomme ich eine Antwort, ebenfalls 5 Byte. Die will ich in ein iKO "Status" schreiben und anzeigen lassen, klappt aber mit meinen Einstellungen siehe Anhang nicht. Das iKO bleibt leer. Was mache ich falsch?

Danke schon mal!

[marco0305]

Hi,

I woud be very interested as well to have a TCP module that can receive on the same port as it sends!
It will solve the telnet port problem on the HS. Finally a lot of other devices can be integrated with the HS with bidirectional control.

It can be done if I only knew how! I'm surprised nobody ever made one.
Maybe we see something on L&B.

Nils if you ever find a moment! Thx

[EIB-TECH]

Ich guck mir das sonst die Tage mal an ob ich den TCPBiDir mal völlig DUMM mal umschreibe. (E1 IP E2 Port E3 connect E4 sende zu TCP /A1 empfange TCP A2 connected A3 SystemLOG)


Das könnte man dann individuell nutzen.

gucken wir mal

Hi Nils,

hast du schon mal gekuck ???

[makki]

Kuemmer Dich doch lieber mal um den 1 Wire-Zählerbaustein, so dass der WMZ mit dem Wiregate out-of-the-box geht *fg*

Geht doch schon laaang

*** Features:
* Support fuer DS2423 Counter-Module
...
-- 2009-11-13 22:14 +0200 : WireGate Development <devel@wiregate.de>

Makki

[swenga]

P.S.: Da fällt mir ein, das ich die Anbindung der AI/Altenheim - äh Siemens - WP von swenga nochmal irgendwann ohne Windows-hobel machen wollte

Mönsch makki,

du musst Zeit haben. Klopp das Ding doch in ne VM und schon hostet es auch Dein Linux. Wird wahrscheinlich auf dem Alix-Board ein bisschen knapp, aber es gibt ja auch erwachsene Rechner

Kuemmer Dich doch lieber mal um den 1 Wire-Zählerbaustein, so dass der WMZ mit dem Wiregate out-of-the-box geht *fg*

mfg

[makki]

so dass es wahrscheinlich wieder eine externe Applikation wird.

Ich glaube zu diesem Schluss kamen wir alle irgendwann Solange diese externe Sache nicht singulär dafür läuft ist es IMHO auch die sinnvolle Lösung, ein socat der aus TCP UDP macht reicht ja ggfs. (wenn man den Rest denn im HS parsen will/kann)

alles Gut .....

Puh, ok, alles gut

Makki

P.S.: Da fällt mir ein, das ich die Anbindung der AI/Altenheim - äh Siemens - WP von swenga nochmal irgendwann ohne Windows-hobel machen wollte

[NilsS]

@Swen: stand dürfte sein: HS&persistente TCP-Verbindung: is nich (ohne grobe "Hacks")

Naja, vielleicht gibts das ja bald in supported

Nils, Du vermagst nicht nur B&L nen schrecken einzujagen Was ist/fehlt um diesen schlimmen Zustand hoffentlich ganz schnell wieder zu ändern ?

alles Gut ..... die Sachen für den HS hab ich doch alle eigentlich fast fertig rumliegen ....

[swenga]

Hallo zusammen,

danke fuer die Antworten. Das ist natuerlich suboptimal. Dann stellt sich die Frage wozu TCP beim Senden/Empfangen enthalten ist und wie der Empfang realisiert wird. Spätestens hier muesste die Session doch erhalten bleiben, da der HS ja nicht weiss wann alle Daten gesendet wurden.

Bytecode wäre wohl die Allround-Lösung um so etwas zu erschlagen, allerdings haengt mir die Neustart-Orgie am HS mittlerweile sonstwo, so dass es wahrscheinlich wieder eine externe Applikation wird.

mfg

[makki]

@Swen: stand dürfte sein: HS&persistente TCP-Verbindung: is nich (ohne grobe "Hacks")

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Nils, Du vermagst nicht nur B&L nen schrecken einzujagen Was ist/fehlt um diesen schlimmen Zustand hoffentlich ganz schnell wieder zu ändern ?

Makki

[epogo]

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Ups... NilsS.... Wird sich bei Gira / Dacom was tun das du wieder weiter entwickeln willst ?

[swenga]

Wenn ich dich also richtig verstehe, dann möchtest du ein Moxa per TCP session, am besten kontinuierlich verbunden haben, richtig ?

Korrekt. Wobei ich nicht direkt auf den Moxa gehen würde sondern auf nen Server-Port einer Win-/Linux-Applikation, die dann die spezielle Umsetzung der GSM-ASCII-API macht (Leichter zu entwickeln, da online debug-bar).

Aus derzeitiger Sicht werde ich wahrscheinlich folgendes machen:
-Kommunikation HS zu App via TCP, Session wird nur aufgebaut bei vorliegenden Daten und dann wieder geschlossen, Paketverluste werden nicht toleriert (Alarmmeldungen!)
-Kommunikation App zu HS via UDP, daher triggert jeder Empfang eine Auswertung, Verluste werden hier akzeptiert, da die Applikation ihren GSM-Status sowieso regelmaessig wiederholt und als ASCII-XML an den HS schickt.

Die Email-Alarmierungen würde ich dann auch über die Applikation erledigen. Ich habe im HS zwei Email-Alarmierungen hinterlegt, die eine kommt nachweislich immer zweimal, obwohl nur ein Trigger ausgeloest wird....

mfg

[NilsS]

Wenn ich dich also richtig verstehe, dann möchtest du ein Moxa per TCP session, am besten kontinuierlich verbunden haben, richtig ?

Es könnte evtl. auch ein Modem am Com Port des HS gehen, das würde kaum einen Unterschied machen (solange keine FT1.2 da dran hängt )

Der Baustein sollte gethreaded werden, damit die Logik nicht gebremst wird.

Ich guck mir das sonst die Tage mal an ob ich den TCPBiDir mal völlig DUMM mal umschreibe. (E1 IP E2 Port E3 connect E4 sende zu TCP /A1 empfange TCP A2 connected A3 SystemLOG)


Das könnte man dann individuell nutzen.

gucken wir mal

[swenga]

Hallo Nils,

ich hatte die Woche mal geschrieben, dass durch die fehlende Uebertragungssicherung beim DACOM-SMS-Baustein (Loesung mit GSM-Modem) immer wieder mal Benachrichtigungen floeten gehen. Der Baustein erkennt die fehlende Quittung, setzt einen Fehlerausgang und das wars. Kein Resend oder so was...

Daher will ich das Gatewaying auslagern, also irgendwo eine Applikation, die Daten vom HS entgegennimmt und sie aufbereitet dann an die serielle Schnittstelle für das GSM-Modem schickt. Im Rückweg dann kommen Statusdaten (einkommende SMS, Calls, Signallevel etc) zurueck an den HS.

Wegen Übertragungssicherung wäre dann TCP meine Wahl. Wenn ich jetzt jeweils einen Eintrag bei IP-Senden und einen bei IP-Empfangen mache, wird daraus aber wie ich befuerchte nicht eine einzige Session, unsynchronisiert wird der HS dann den Port öffnen, Daten senden, wieder schliessen etc.

Eventuell koennte man eine Webafrage missbrauchen: Da wären Sende- und Empfangsdaten immer in einer TCP-Session. Dann gibts halt ein Command "Send SMS ....." und zurueck ein "HTTP OK" und ein weiteres Command "Get Status" und dann zurueck die Status-Daten in XML.

Oder man loest das ganze als Bytecode-Baustein

mfg


PS: Nils klonen, gute Idee. Ich nehm auch einen. Werde ihn auch fuettern und hegen, fest versprochen

[Bodo]

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Hoi
Könnte bitte mal jemand den Nils klonen. So drei bis vier mal...

[NilsS]

Hi Swen,

beschreib mal was du machen willst.

Alles was der HS per default onbaord hat taugt dazu nicht.

Du kannst die den source vom Fritzbox Callmon nehmen und verändern, das hat Holger (eckerho1) auch für seinen Squeeze Baustien gemacht.

für kurze befehle ala telnet, kannst du sonst auch den urllib Baustein verwenden.

Wenn du Hilfe brauchst, meld dich einfach.

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht