Anbindung an openHCAN

Begonnen von GU!DO, 11 Oktober 2017, 10:30:09

Vorheriges Thema - Nächstes Thema

GU!DO

Guten Morgen zusammen,

ich bin neu hier im Forum, und lese mich grad ein (bzw. habe das Anfänger Tutorial erfolgreich abgeschlossen  ;) ).

Ich habe vor Jahren mein Haus mit dem openHCAN.org Bussystem ausgerüstet, welches sehr zuverlässig läuft, aber von mir bisher nur mittels Tastern bedient wird.
Ich bin auf FHEM gekommen, da ich gerne ein Web-UI für mein Bussystem aufsetzen möchte.

Um mit dem Bus zu Kommunizieren, bietet sich ein openHCAN-Tool namens telican an. Es bietet einerseits die Möglichkeit von der Shell aus Befehle an den Bus zu senden, anderersets bietet es einen Dump-Modus an, mit dem sämtlicher Busverkehr auf stdout ausgegeben wird.

Mittels Aufruf des telican Befehls "(echo "lampe test ein" | telican)" aus einem notify heraus kann ich eine Lampe einschalten. Das ist zwar noch keine "saubere" Anbindung, aber sie funktioniert erstmal.

Was für mich aber mindestens genau so wichtig wäre, ist die Möglichkeit die Ausgaben des Telican-Dump in Echtzeit zu visualisieren. Dazu müßte ich entweder den Telican-Output auf stdout einlesen, oder dessen Quelltext (C Code) so ändern, dass der Busverkehr über einen anderen Weg zu FHEM gelangt.

Mit habe rudimentäre Programmierkenntnisse in verschiedenen Sprachen (Pascal, C und python). Ich möchte mich gerne in perl einlesen, und würde mir zutrauen vorhandenen Code Schritt für Schritt anzupassen.

Da mir einerseits noch der Überblick und die Erfahrung fehlt, ich aber andererseits meinem primären Ziel näher kommen möchte, wären meine Fragen daher:

1. Welchen Weg der Kommunikation würdet Ihr für den "saubersten" halten?
2. Fällt euch ein Modul ein, das ähnliches tut? (Das würde ich dann "umbauen". Habe hier bisher, trotz intensiver Suche, leider nix gefunden...)

Vielen Dank

Guido



CoolTux

Wie klebt denn Dein Raspi am Bus? USB,RS232 oder FastEthernet?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

Zitat1. Welchen Weg der Kommunikation würdet Ihr für den "saubersten" halten?
Zwei (oder mehr) FHEM-Module:
- das erste (physikalisches) Modul kommuniziert nur mit dem Bus, indem das Geraet, das auf dem Bus zugreift, oeffnet (Stichwort DevIo_OpenDev), und fertige Pakete vom Bus liest bzw. solche auf dem Bus schreibt. Fertig empfangene Pakete werden an die logischen Module (Stichwort Dispatch) weitergegeben.
- logische Module, die sowas wie eine Lampe, Schalter, usw. implementieren. Diese bekommen die  Rohdaten vom Dispatch, wenn sie ein ParseFn implementieren, und generieren daraus  FHEM-Events (Stichwort readings*Update). In die andere Richtung werden set Befehle zu Rohdaten konvertiert, und an das physikalische Modul weitergegeben (Stichwort IOWrite).

Siehe auch
  https://wiki.fhem.de/wiki/DevelopmentModuleIntro

Beispiele dafuer gibt es viele (CUL vs. FS20, ZWDongle vs. ZWave, TUL vs EnOcean), leider sind die meisten schon alt, gewachsen und deswegen zum Kopieren zu kompliziert.

Aber vielleicht faengt man mit was Kleineres an, um Erfahrung zu sammeln :)

GU!DO

Hallo CoolTux,
Zitat von: CoolTux am 11 Oktober 2017, 11:53:16
Wie klebt denn Dein Raspi am Bus? USB,RS232 oder FastEthernet?
Der Rechner hängt über ein Host-Interface am Bus, dieses ist mittels USB angeschlossen.

CoolTux

Na da gibt es ja einige Beispiele wie man die Daten dann abgreifen kann.
Sehr wichtig ist das was Rudi gesagt hat. Wenn dann geht das ganze nur sauber über ein 2 stufiges Modul.
Siehe dazu auch den Developer Guide im Wiki. Das ist der Link von Rudi.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

GU!DO

Hallo zusammen,

ich habe mir den Developer Guide angesehen, und sogar ein wenig verstanden.
Ich habe ab Mitte der nächsten Woche Zeit mich einzulesen und hoffe, danach ein wenig mehr zu verstehen.

Es wäre natürlich schön, wenn es ein "kleines" zweistufiges Modul geben würde, um die Funktionsweise zu erkennen, aber vielleicht klappt es ja auch so.

Vielen Dank auf jeden Fall

Schönen Abend noch

Guido

CoolTux

Bei Fragen kannst Du Dich an einen Developer Deines Vertrauens wenden.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

GU!DO

Da ich hier, wie gesagt neu bin, weiß ich noch nicht wem man vertrauen kann.  ;)
Hast Du einen Tip?

CoolTux

Mein Tip. Lese Dich so ein bisschen durch das Forum. Einfach mal ein paar Wochen das Forum verfolgen und dann schaust Du welcher der Developer Antworten Dir so erscheinen das Du denjenigen Developer als Mentor aussuchen würdest.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

GU!DO

Guten Morgen zusammen,

ich habe die letzten Wochen damit verbracht mich so intensiv wie möglich mit FHEM und perl zu beschäftigen.

Ich habe mir auch viele Module angesehen. Vor allem habe ich nach "kleinen" Modulen Ausschau gehalten, welche in etwa das tun was ich benötige.
Dabei bin ich auf die pilight Module gestoßen. Sie arbeiten nach den 2-Modul-Prinzip das Ihr für mein Vorhaben ja empfohlen habt.

Ich kann bereits rudimentär Daten aus FHEM an meinen Bus senden. Also LampenDevice in FHEM klicken, physisches Licht geht an. Das war schon mal ein gutes Gefühl.  :D

Nun geht es aber um dem "Rückweg".
Wenn ich mit einem Taster des Busses eine Lampe einschalte, soll FHEM möglichst ohne Verzögerung den Status des zugehörigen Devices auf "EIN" ändern.

Hier beiße ich leider noch auf Granit und hätte ein paar Fragen, die ich totz intensiver Suche nicht klären konnte.

Das physiche Modul von pilight (10_pilight_crtl.pm) nutzt DevIo zur Kommunikaton mit dem pilight daemon. "Leider" unterstützt DevIo kein UDP. 

Daher habe ich folgendes probiert (ist ein Umbau von LG_WebOS dessen Studium hatte CoolTux im "DevIO und udp" Fred empfohlen):


  0     Log3 $name, 4, "HCAN_log ($name) - Baue Socket Verbindung auf";
  1 ----
  2
  3     my $socket = new IO::Socket::INET   (   PeerHost => 'localhost',
  4                                                                     PeerPort => '3600',
  5                                                                     Proto => 'udp',
  6                                                                     Type => SOCK_DGRAM
  7                                                                     #Timeout => 0.1
  8                                         )
  9         or return Log3 $name, 4, "HCAN_log ($name) Couldn't connect to $host:$port";      # open Socket
10 --------
11     $hash->{FD}    = $socket->fileno();
12     $hash->{CD}    = $socket;         # sysread / close won't work on fileno
13     $selectlist{$name} = $hash;
14 ----
15     Log3 $name, 4, "HCAN_log ($name) - Socket Connected";


Das scheint auch soweit zu funktionieren, denn ich habe nach Zeile 12 die Einträge:
'FD' => 17, und
'CD' => bless( \*Symbol::GEN22, 'IO::Socket::INET' ) in $hash.

Meine Fragen wären:

Wenn nun per UDP Daten "geliefert" werden , müßte doch eingentlich _Read aufgerufen werden!?! Es passiert aber nix... Warum???

Was passiert, wenn gelieferte Daten nicht direkt verarbeitet werden können, weil die Select Schleife grad mit einer anderen Abfrage beschäftigt ist?

Welchen Sinn macht die 2-Modul-Technik, wenn die Daten des physischen Moduls direkt durch FHEMs select() in der Haupt-Schleife verarbeitet werden?
Ich dachte, das physiche Modul kommuniziert mit dem externen Gerät, und leitet die Daten an das Logische Modul weiter, welches es an FHEM übergibt.
Oder habe ich das Konzept bzw. den Quellcode von pilight_ctrl falsch verstanden?

Vielen Dank schonmal für Eure Hilfe

Guido

CoolTux

Hallo Guido,

Du hast ja, zu mindest hier ersichtlich, lediglich die connect Routine. Da fehlt ja nun die ReadFn und die WriteFn und natütlich die entsprechende Zuweisung zu FHEM.

Das alles findest Du in der LGWebOS ganz oben in _Initialize($)
Dort steht dann auch drin welche Deiner Funktion die ReadFn ist. Diese wird dann aufgerufen und die Funktion holt die Daten ab.

sub LGTV_WebOS_Read($) {

    my $hash = shift;
    my $name = $hash->{NAME};
   
    my $len;
    my $buf;
   
   
    Log3 $name, 4, "LGTV_WebOS ($name) - ReadFn started";

    $len = sysread($hash->{CD},$buf,10240);
   
    if( !defined($len) or !$len ) {

        LGTV_WebOS_Close($hash);

        return;
    }
   
unless( defined $buf) {
        Log3 $name, 3, "LGTV_WebOS ($name) - no data received";
        return;
    }
}


hier werden jetzt dann die Daten abgeholt und können dann weiter verarbeitet werden. fhem.pl selbst verarbeitet keine Daten. Es schaut nur nach ob Daten anliegen und wenn ja ruft es die passende Readfunktion auf.
Zeige mal bitte Dein physikalisches Modul. Dann kann man es sich zusammen anschauen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

GU!DO

Hallo CoolTux,

Danke für die schnelle Antwort. Ich habe den geposteten Code in LGWebOS "eingebaut". Also seinen TCP Socket ersetzt.
Außerdem habe ich in alle sub's print Ausgaben eingefügt, um zu sehen, wann was aufgerufen wird.

Ich denke, dass fhem ja nun zumindest das _Read aufrufen müßte, sobald Daten per UDP eintreffen. Auch wenn der Read mit den Daten nix anfagen kann, ist ja kein LG-TV auf der anderen Seite.
Es erfolgt jedoch kein Aufruf von Read.

Ich habe mich, parallel zum Modul, mit einem UDP Client auf meinen hcan Server-Deamon verbunden, so dass ich sicher sein kann, dass UDP-Pakete gesendet werden auf die das Modul dann reagieren müßte.

LGWebOS durchläuft zyklisch die Set und TimerStatusRequest Funktinen, aber  Read wird nicht aufgerufen.


CoolTux

Das wird so nichts. Das alles (TimerStatusRequest und/oder Set) haben damit gar nichts zu tun.
Du brauchst erstmal ein kleines Grundgerüst. Ich habe da erst neulich jemanden mit geholfen. Ich suche Mal.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Schau mal hier
https://forum.fhem.de/index.php/topic,78101.msg700396.html#msg700396

Bau dir erstmal ein Modul was so ein Grundgerüst hat wie das was ich in dem Thread gemacht habe.
Am Ende kann dann ein mit dem Modul angelegtes Device eine Verbindung auf machen und empfangende Daten im Log ausgeben. Das ist deine Anfangsbasis zum verstehen.

Wenn Fragen sind Frage einfach, aber am besten immer mir Code. Vergiss erstmal Dein Modul, baue Dir erstmal etwas kleines zum verstehen, und das baust du dann aus.
Der Rest kommt von alleine.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

GU!DO

OK. Vielen Dank. Das hatte ich eigentlich auch so vor.

Das, was am besten zu meinem "Problem" passte, war pilight. Das ist ja auch nicht sonderlich groß. Nur nutzt es eben devio...

Was mir nur noch nicht klar ist:
Das Modul um das es im Thread geht, sammelt doch Daten eines externen Vissman Daemon. Müßte es, um "ordnungsgemäß" angelegt zu sein, nicht in 2 Modul Technik ausgelegt werden?