Eigene Telegramme bei fhem anliefern

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich habe es vor geraumer Zeit hier schon mal gelsen, aber ich finde es
einfach nicht wieder:

Ich möchte gerne mit einem eigenen kleinen Python-Programm CUL/N-
kompatible Telegramme bei fhem anliefern und später ggf.auch abholen
und weiterleiten.

Langform/Hintergrund:
Ich bin gerade dabei meinen eigenen kleinen Hausbus zu bauen. Dabei
setze ich auf CAN-Transceiver. Als physikalisches Gateway habe ich
einen USB-CAN-Bus-Adapter im Einsatz und das Debugging läuft über ein
kleines Python-Programm. Das ganze ist dezentral ausgelegt und
benötigt keinen zentralen Server. Weiterhin habe ich fast seit
Projektstart eine mittlerweile recht umfangreiche fhz/fhem-
Installation am laufen die ich gerne so behalten möchte und mit meinem
Bus erweitern möchte.
Dazu möchte ich die relevanten Bus-Telegramme ausleiten und in der
Form "Fhhhhaa(ccee)" an fhem weitergeben, so dass ich dort
entsprechende Alias-Geräte habe. Eine direkte Einbindung bei fhem
entfällt, da ich weder so tiefgehende Perlkenntnisse besitze, noch
dass alle Busnachrichten zu fhem sollen/müssen. Außerdem sollen hier
noch weitere Aufgaben wie Konfiguration und Softwaredownloads erledigt
werden. Mein Programm soll also so eine Art Proxy darstellen.
Und irgendwo habe ich hier schon mal eine ähnliche Aufgabenstellung
gelesen, finde Sie aber nicht wieder.... Kann mich mal jemand bitte in
die Richtung stubsen?

Gruß
 Holger

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Axel hatte 2009 18_WBS.pm & 99_CGI_RAWMSG.pm angekündigt, such' mal nach "Web-Based-Sensors: Sensordaten (z.B. temperatur) per http nach FHEM" ...
-kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Axel hatte 2009 18_WBS.pm & 99_CGI_RAWMSG.pm angekündigt, such' mal nach "Web-Based-Sensors: Sensordaten (z.B. temperatur) per http nach FHEM" ...
-kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Ich möchte gerne mit einem eigenen kleinen Python-Programm CUL/N-
> kompatible Telegramme bei fhem anliefern und später ggf.auch abholen
> und weiterleiten.

Falls Du eine Schnittstelle auf RAW Ebene willst, dann musst Du das FHEM2FHEM
Protokoll implementieren:

- damit fhem deinem Programm Daten schickt, meldet man mit "inform raw" Bedarf
  an.  FS20/HMS/FHT ist aber leider auch bei einem CUL in dem etwas
  unleserlichen FHZ1x00 Format damit das FS20 Modul CUL und FHZ bedienen kann.

- um Aktionen in fhem auszuloesen verwendet man
    iowrite MyCUL HEX-CODED-RAWDATA
  MyCUL muss vorher als CUL definiert sein (evtl mit Geraet none).

- Fuer die andere Richtung oeffnet man in python ein Server-Socket, und man
  definiert damit in fhem ein FHEM2FHEM Geraet. Das python Programm muss
  "inform raw" und iowrite implementieren

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Genau das hatte ich gesucht... Vielen Dank!

On 11 Nov., 08:46, Kai 'wusel' Siering wrote:
> Axel hatte 2009 18_WBS.pm & 99_CGI_RAWMSG.pm angek ndigt, such' mal nach "Web-Based-Sensors: Sensordaten (z.B. temperatur) per http nach FHEM" ...
> -kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das hört sich nicht gar so kompliziert an, ich werde mir das, wenn der
Rest einigermaßen läuft mal näher ansehen.
Zunächst scheint mir aber der Workaround mit 18_WBS.pm &
99_CGI_RAWMSG.pm sehr fix zu realisieren.

Vielen Dank!

On 11 Nov., 09:30, Rudolf Koenig wrote:
> > Ich m chte gerne mit einem eigenen kleinen Python-Programm CUL/N-
> > kompatible Telegramme bei fhem anliefern und sp ter ggf.auch abholen
> > und weiterleiten.
>
> Falls Du eine Schnittstelle auf RAW Ebene willst, dann musst Du das FHEM2FHEM
> Protokoll implementieren:
>
> - damit fhem deinem Programm Daten schickt, meldet man mit "inform raw" Bedarf
>   an.  FS20/HMS/FHT ist aber leider auch bei einem CUL in dem etwas
>   unleserlichen FHZ1x00 Format damit das FS20 Modul CUL und FHZ bedienen kann.
>
> - um Aktionen in fhem auszuloesen verwendet man
>     iowrite MyCUL HEX-CODED-RAWDATA
>   MyCUL muss vorher als CUL definiert sein (evtl mit Geraet none).
>
> - Fuer die andere Richtung oeffnet man in python ein Server-Socket, und man
>   definiert damit in fhem ein FHEM2FHEM Geraet. Das python Programm muss
>   "inform raw" und iowrite implementieren

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 11 Nov., 09:30, Rudolf Koenig wrote:
> Falls Du eine Schnittstelle auf RAW Ebene willst, dann musst Du das FHEM2FHEM
> Protokoll implementieren:
>
> - damit fhem deinem Programm Daten schickt, meldet man mit "inform raw" Bedarf
>   an.  FS20/HMS/FHT ist aber leider auch bei einem CUL in dem etwas
>   unleserlichen FHZ1x00 Format damit das FS20 Modul CUL und FHZ bedienen kann.
>
> - um Aktionen in fhem auszuloesen verwendet man
>     iowrite MyCUL HEX-CODED-RAWDATA
>   MyCUL muss vorher als CUL definiert sein (evtl mit Geraet none).
>
> - Fuer die andere Richtung oeffnet man inpythonein Server-Socket, und man
>   definiert damit in fhem ein FHEM2FHEM Geraet. DaspythonProgramm muss
>   "inform raw" und iowrite implementieren

Das heißt ich benötige zwei Verbindungen, richtig? Oder nur eine?

Ich habe jetzt mal mit Python ein Socket geöffnet und in fhem eine
FHEM2FHEM-Verbindung angelegt mit:
define MyCANDummy CUL none 0815
define MyCANServer FHEM2FHEM 192.168.2.2:2000 RAW:MyCANDummy
Ich sehe wie sich fhem anmeldet und ein  "inform raw" absetzt.

Jetzt habe ich bei fhem folgende Devices angelegt:

define MyCANDummy CUL none 0815
attr MyCANDummy dummy 1
attr MyCANDummy room CANtest

define MyCANServer FHEM2FHEM 192.168.2.2:2000 RAW:MyCANDummy
attr MyCANServer room CANtest

define CANFS20dev FS20 0815 00
attr CANFS20dev IODev MyCANDummy
attr CANFS20dev room CANtest

Meine Erwartung war jetzt, wenn ich das F20-Device schalte, ich auf
meinem Server eine Meldung bekomme, wie
CUL MyCANDummy F08150001
die ich dann über eine Hashtabelle in eine CAN-NAchricht überführe.
Offensichtlich ist dem nicht so. Auch denn ich mich mal per Telnet zu
fhem verbinde und ein inform raw absetzte sehe ich keine Reaktion auf
meinen Schaltvorgang.

Wo mache ich denn den Fehler?

Und wie verhält sich FHEM2FHEM wenn der Server mal weg ist? Bisher
scheint er sich ja immer wieder sofort zu verbinden...

Gruß
 Holger

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Wo mache ich denn den Fehler?

attr CANFS20dev IODev MyCANServer

CANFS20dev wird auch automatische angelegt, falls eine entsprechende Nachricht
ueber MyCANServer eintrifft. MyCANDummy wird benoetigt, damit FHEM2FHEM weiss,
wie ein Buchstabensalat zu interpretieren ist: das ist in dem CUL Modul
definiert.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 27 Nov., 12:25, Rudolf Koenig wrote:
> CANFS20dev wird auch automatische angelegt, falls eine entsprechende Nachricht
> ueber MyCANServer eintrifft. MyCANDummy wird benoetigt, damit FHEM2FHEM weiss,
> wie ein Buchstabensalat zu interpretieren ist: das ist in dem CUL Modul
> definiert.

okay, was ist denn dann für fhem z.B. eine gültige Nachricht?

Ich habe jetzt mal meinen Python-Code bei Seite gelassen und es mit:
nc -l 2000 -k
probiert. FHEM verbindet und trennte sich offenbar permanent, denn der
FHEM-Server sagte bei inform on:
FHEM2FHEM MyCANServer CONNECTED
FHEM2FHEM MyCANServer DISCONNECTED
FHEM2FHEM MyCANServer CONNECTED

Nach einem FHEM Neustart habe ich jetzt scheinbar einen stabilen
Connect. Offensichtlich hatte sich FHEM hier verrannt...

Jetzt habe ich beim nc-Listener diverse Befehle probiert. Aber FHEM
zeigt mir keine Reaktion. Wie muss denn die Nachricht aussehen? Ich
habe bisher diverses mal probiert:
So wie ich es eigentlich verstanden habe:
CUL MyCANDummy FD4B501002F
Mal stumpf aus dem FHEM Server kopiert:
CUL MyCUN TBC4B5C01
FHZ MyFHZ 810b04680101a0018171c20011
CUL MyCUN TBC4B5C01
Un nochmal mit iowrite:
iowrite CUL MyCANDummy FD4B501002F

Bei allen Versuche habe ich zwei Terminalsessions zum FHEM-Server
offen, eine mit inform on und eine inform raw. Meine eingaben beim nc-
Listenner zeigen keinerlei Reaktion??

Ist CUL MyCANDummy FD4B501002F denn keine gültige Nachricht?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Ist CUL MyCANDummy FD4B501002F denn keine gültige Nachricht?

Ich meine nicht, FS20 sollte im FHZ Format kommen. Du darfst genau das
reinstecken, was beim inform raw sichtbar ist.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 27 Nov., 18:52, Rudolf Koenig wrote:
> Ich meine nicht, FS20 sollte im FHZ Format kommen. Du darfst genau das
> reinstecken, was beim inform raw sichtbar ist.

Okay, jetzt habe ich es hinbekommen. Wenn ich die Nachricht bei meinem
Netcat-Listener eintippe, wird sie von FHEM richtig erkannt. Damit
würde ich wohl die Richtung CAN zu FHEM hinbekommen.
Für den umgekehrten Weg hätte ich jetzt folgendes Vorgehen vermutet:
Von meinem Server eine Telnetsession zu FHEM öffnen, inform raw
absetzten und die Nachrichten auf für den CAN-Bus gültige Telegramme
überwachen, ggf. übersetzen und an den CAN-Bus senden.
Wenn ich jetzt jedoch im Frontend das von autocreate neu angelegte
FS20-Device schalte, sehe ich keinen entsprechenden Befehl in meiner
"inform raw"-Telnetsession. Auch auf meinem Netcat-Listener kommt
keine Nachricht an. Lediglich in einer weiteren Telnetsession, wo ich
"inform on" abgesetzt habe sehe ich "FS20 FS20_d4b502 on".

Muss ich jetzt hier iowrite einsetzten? In welchem Zusammenhang?
iowrite schreib nach meinem Verständnis RAW-Daten an ein Device wie
CUL  oder FHZ... das ist doch nicht das, was ich jetzt brauche... oder
doch?





BTW: Kann es eigentlich sein, dass autocreate nicht funktioniert,
falls noch "Reste" des Devices in FHEM existieren? (z.B. Filelog)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Für den umgekehrten Weg hätte ich jetzt folgendes Vorgehen vermutet:

Falsch Falls einem Geraet (z.Bsp. mydev) ein FHEM2FHEM Instanz als IODev
zugewiesen wurde, dann wird beim ersten Schreibversuch (d.h. set/get mydev)
eine zweite TCP/IP Verbindung zum Partner FHEM geoeffnet, und

  iowrite $remoteIoDev $fn $msg\n

abgesetzt. $fn/$msg ist Geraete- (d.h. $remoteIoDev) abhaengig, und benoetigt
normalerweise keine komplexe Uebersetzung. Beispiel bei schalten von FS20
Geraet:

  iowrite CUL 04 010101

Dabei ist 04 und 010101 FHZ spezifisch, und wird z.Bsp vom 00_CUL.pm ignoriert.
Der Rest der Daten wid mit dem Prefix "F" direkt an das adressierte  CUL
geschickt.

> BTW: Kann es eigentlich sein, dass autocreate nicht funktioniert,
> falls noch "Reste" des Devices in FHEM existieren? (z.B. Filelog)

autocreate selber ist eigentlich unschuldig, der ist nur ein etwas aufgebohrtes
notify fuer das Event UNDEFINED, und ruft selber "define" auf.
Ein UNDEFINED Event wird dann generiert, wenn im Modul-Internen hash
($modules{NAME}{defptr}{) beim ParseFn Aufruf kein Eintrag fuer
existiert, wiederum kommt aus dem Nachricht, was ParseFn verdauen
sollte, und ist Modul-spezifisch.

delete sollte UndefFn aufrufen, der wiederum aus defptr entfernen
muss. Ich sehe gerade, dass CUL_HM gar kein UndefFn hat, d.h. HM Geraete
wuerden nur nach einem fhem Neustart wieder UNDEFINED erzeugen, ein delete
reicht da nicht.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 28 Nov., 09:33, Rudolf Koenig wrote:
> > F r den umgekehrten Weg h tte ich jetzt folgendes Vorgehen vermutet:
>
> Falsch Falls einem Geraet (z.Bsp. mydev) ein FHEM2FHEM Instanz als IODev
> zugewiesen wurde, dann wird beim ersten Schreibversuch (d.h. set/get mydev)
> eine zweite TCP/IP Verbindung zum Partner FHEM geoeffnet, und
>
>   iowrite $remoteIoDev $fn $msg\n
>
> abgesetzt. $fn/$msg ist Geraete- (d.h. $remoteIoDev) abhaengig, und benoetigt

Okay,vermutlich auf den gleichen Port, also muss ich wohl einen
zweiten Thread implementieren...

Vorhin war ich ein bißchen Joggen und unter der Dusche kam mir
plötzlich die Idee, kann man nicht einfacher ein CUN-Device
definieren? Dort dürften ja auch nur die betreffenden Telegramme
eintreffen, RX und TX-Befehle sind identisch, ich brauch kein
Multithreading... oder liege ich da falsch.
 Also eben fix ein nc -l 2001 -k und ein CUN-Device definiert. Dann
sehe ich dreimal ein großes V. Darauf hin habe ich mal "V 1.40 CUN"
und 2 Return gesendet und erhalte "X21" "T01", dann ist aber
Funkstille. Habe schon mal ein 0000 für den Hauscode gesendet, ohne
Erfolg...


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> kann man nicht einfacher ein CUN-Device definieren?

Sicher, sollte noch einfacher sein. Ich wuerde an deine Stelle zum besseren
Verstaendnis in CUL_SimpleWrite und in DevIo_SimpleRead debugging einbauen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 28 Nov., 17:22, Rudolf Koenig wrote:
> Sicher, sollte noch einfacher sein. Ich wuerde an deine Stelle zum besseren
> Verstaendnis in CUL_SimpleWrite und in DevIo_SimpleRead debugging einbauen.

Der Tipp war Gold wert... vielen Dank. Ich ahme jetzt mit meinem
Python-Server eine CUN nach und übersetze die Befehle anhand einer
Tabelle in Telegramme zum USBCAN-Adapter und umgekehrt. Geht sehr
gut... Danke für die Unterstützung.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com