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 (http://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
Wie klebt denn Dein Raspi am Bus? USB,RS232 oder FastEthernet?
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 :)
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.
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
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
Bei Fragen kannst Du Dich an einen Developer Deines Vertrauens wenden.
Grüße
Da ich hier, wie gesagt neu bin, weiß ich noch nicht wem man vertrauen kann. ;)
Hast Du einen Tip?
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
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
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.
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.
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.
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.
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?
;D
Ok noch mal. Schau mal bitte genau hier
https://forum.fhem.de/index.php/topic,78101.msg700581.html#msg700581
Grundgerüst. Es geht darum das Du erstmal verstehst wie die Daten fließen, wo sie sind, wer schaut ob Daten an liegen und wer sie wie am Ende ab holt.
Das zweistufige ist doch dann nur noch ein weiterreichen der Daten an den Dispatcher der dann entsprechend der Vorgaben die ParseFn des logischen Modules auf ruft.
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module
Aber so weit sind wir noch lange nicht. Erstmal die Basic. Schau dir bitte erstmal die Moduldatei an die ich in dem genannten Thread als Gerüst angehangen habe.
Hier geht es nur darum ein Device zu erstellen, danach von Hand einen Netzwerksocket auf zu bauen und die Info für den Socket in die selectlist zu schicken. Damit schaut fhem.pl in der Hauptschleife immer nach ob dort Daten anliegen. Wenn ja ruft fhem.pl die Readfunktion der Moduldatei auf und erst dort werden dann die Daten abgeholt.
Lass uns das erstmal in Ruhe hinbekommen. Dann kommt der Rest nach und nach.
Zitat von: GU!DO am 31 Oktober 2017, 11:24:03
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?
Um kurz auch diese Frage zu beantworten.
Wann glaubst du baut man ein 2 stufiges Modul?
Meiner Meinung nach erst sobald Du über ein physikalisches Modul (Bridge) mehrere logische Geräte an sprichst. Wie viele Vissmann Heizungen glaubst du hat ein Hausbesitzer?
Anders würde es bei Thermostaten aussehen. Hier können zum Beispiel mehrere Thermostate über ein Gateway angesprochen werden.
ZitatWann glaubst du baut man ein 2 stufiges Modul?
Ich habe den Wikieintrag "DevelopmentModuleIntro" gelesen (Auszug):
X_Parse Zustellen von Daten via Dispatch() vom physischen Modul zum logischen Modul zwecks der Verarbeitung.
X_Write Zustellen von Daten via IOWrite() vom logischen zum physischen Modul um diese an die Hardware weiterzureichen.
Das habe ich so verstanden, dass ich ein:
phyisches Modul habe, welches auf der einen Seite mit der externen Hardware redet, und auf der anderen mit einem
logischen Modul, welches einerseits die Daten in FHEM präsentiert und andererseits Ereignisse aus FHEM an das physische Modul zurück gibt.
Wie gesagt, ich schaue mir den Thread an.
Vielen Dank für Deine Hilfe!
Guido
Schau ihn dir an und dann Bau doch einfach mal ein Modul was die Daten vom Bus liest.
So, ich war ein wenig fleißig, habe aber leider noch keinen abschließenden Erfolg gehabt. Daher hoffe ich auf Deine Hilfe.
Erstmal vielen Dank für das Modulskelett. Das hat schon mal geholfen.
Grundsätzlich gehe ich folgender Maßen vor, wenn ich Änderungen am Modul gemacht habe:
1. Ich lösche das Test-Device.
2. ich mache einen Reload des Moduls mit reload...
3. ich Erstelle ein neues Device mit define...
Ich denke das ist so ok?!?
Ich habe das Testmodul mal 78_HCAN_Test.pm genannt. Die Nummer werde ich später noch ändern, jedoch war die 78 unbenutzt, so habe ich bereits nach Eingabe von 78 + Autoconpletion mein Modul im vim geöffnet:
Folgendes wurde geloggt mit dem angepassten Modul: (Verbose auf 5 + am Anfang jeden set's eine Ausgabe seines Namens mit print)
!!!Initialize
2017.10.31 16:58:12 4: WEB_10.20.30.40_43153 GET /fhem?fw_id=67; BUFLEN:0
2017.10.31 16:58:12 4: WEB: /fhem?fw_id=67 / RL:1257 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.31 16:58:12 4: Connection accepted from WEB_10.20.30.40_43156
2017.10.31 16:58:20 4: Connection closed for WEB_10.20.30.40_43150: EOF
2017.10.31 16:58:32 4: Connection closed for WEB_10.20.30.40_43154: EOF
2017.10.31 16:58:38 4: WEB_10.20.30.40_43153 POST /fhem&fw_id=67&fwcsrf=csrf_127224906171181&cmd=define+HCAN_Test+HCAN_Test+localhost; BUFLEN:0
2017.10.31 16:58:38 5: Cmd: >define HCAN_Test HCAN_Test localhost<
!!!Define
2017.10.31 16:58:38 3: HCAN_Test (HCAN_Test) - defined with host localhost
2017.10.31 16:58:38 5: Starting notify loop for HCAN_Test, 1 event(s), first is Initialized
2017.10.31 16:58:38 5: createNotifyHash
2017.10.31 16:58:38 5: End notify loop for HCAN_Test
2017.10.31 16:58:38 5: Starting notify loop for global, 1 event(s), first is DEFINED HCAN_Test
2017.10.31 16:58:38 5: createNotifyHash
2017.10.31 16:58:38 5: End notify loop for global
2017.10.31 16:58:38 4: WEB_10.20.30.40_43153 GET /fhem?detail=HCAN_Test&fw_id=67; BUFLEN:0
!!!Set
!!!Set
2017.10.31 16:58:38 4: WEB: /fhem?detail=HCAN_Test&fw_id=67 / RL:2548 / text/html; charset=UTF-8 / Content-Encoding: gzip
Der 3. Parameter in set enthält einen Wert, der in $cmd übernommen wird. Wenn ich $cmd händisch auf "connect" setze, wird der socket geöffnet:
!!!Define
2017.10.31 17:28:32 3: HCAN_Test (HCAN_Test) - defined with host localhost
2017.10.31 17:28:32 5: Starting notify loop for HCAN_Test, 1 event(s), first is Initialized
2017.10.31 17:28:32 5: createNotifyHash
2017.10.31 17:28:32 5: End notify loop for HCAN_Test
2017.10.31 17:28:32 5: Starting notify loop for global, 1 event(s), first is DEFINED HCAN_Test
2017.10.31 17:28:32 5: createNotifyHash
2017.10.31 17:28:32 5: End notify loop for global
2017.10.31 17:28:32 4: WEB_10.20.30.40_43322 GET /fhem?detail=HCAN_Test&fw_id=33; BUFLEN:0
!!!Set
$VAR1 = 'Dumper =connect';
!!!Open
2017.10.31 17:28:32 4: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
2017.10.31 17:28:32 5: Starting notify loop for HCAN_Test, 1 event(s), first is connected
2017.10.31 17:28:32 5: End notify loop for HCAN_Test
2017.10.31 17:28:32 4: HCAN_Test (HCAN_Test) - Socket Connected
!!!Set
$VAR1 = 'Dumper =connect';
!!!Open
2017.10.31 17:28:32 4: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
2017.10.31 17:28:32 5: Starting notify loop for HCAN_Test, 1 event(s), first is connected
2017.10.31 17:28:32 5: End notify loop for HCAN_Test
2017.10.31 17:28:32 4: HCAN_Test (HCAN_Test) - Socket Connected
Aktuell hätte ich folgende Fragen:
1. Öffnet FHEM _Set generell nach einem Define - oder wo wird FHEM mitgeteilt was es öffnen soll?!?
2. Woher soll $cmd den Wert "connect" bekommen, so dass das die Funktion _Open aufgerufen wird, um den Socket zu öffnen?
3. Damit Daten Empfangen werden, muß ich ein Initialsierungspaket an den Daemon senden. Bringe ich das am besten am Abschluß der set Funktion unter?
4. Damit das Modul dauerhaft liest, müssen keep_alive Pakete an den Daemon gesendet werden. In meinem Testprogramm hcan2.pl habe ich das in einer while Schleife mit Try / catch gelöstt. Wie bekomme ich das hier hin.
5. Woher kommen die notifies im Log?
Viiiilen Dank schon mal
Guido
P.S. Ich hänge das angepasste Skelett und mein Testprogramm hcan2.pl an.
Dein Modul kann ich mir erst nachher in Ruhe anschauen.
Ich empfehle nicht global verbose 5 setzen sondern nur für das Modul als Attribut. Dann baust du passende Log Ausgaben ein, am besten alles mit Log3 dann siehst auch gleich was.
Den Connect macht man später automatisch, entweder durch ein InternalTimer aufgerufen am Ende des Define oder was sich eher durch setzt durch ein abfangen des passenden globalen Events.
Das keepAlive kannst Du dann tatsächlich durch das dauerhafte aufrufen einer Funktion erreichen.
Die Set Funktion ist für die User. Da können dann die User entsprechende Aktionen auslösen. Hier kann man einen Connect auslösen.
if( $cmd eq 'statusSOE' ) {
return Connect($hash);
} else {
my $list = 'connect:noArg';
return "Unknown argument $cmd, choose one of $list";
}
Hiermit sollte die nun eine Set Liste im Web angezeigt werden. Und zwar Connect
Habe eben mal geschaut. Sieht doch schon mal gut aus
Was aber fehlt ist
1;
Gehört zwingend ans Ende eines jeden Modules.
Kann es sein das da bis jetzt noch keine Daten eingelesen wurden? Kannst Du noch einmal eine Verbindung machen wo Du nur das verbose vom Device auf 5 stellst?
Hallo,
sorry für die späte Antwort. Ich mußte erst noch Herrscharen von Gespenstern und anderen suspekten Gestalten die vor unserer Haustür herumlungerten mit Süssem versorgen...
ZitatIch empfehle nicht global verbose 5 setzen sondern nur für das Modul als Attribut.
Danke für den Tip.
Ich hatte es im Kommentar zu Log3 so verstanden, dass Verbose Werte in den Modulen nicht mehr berücksichtigt werden - sondern nur noch global.
ZitatDen Connect macht man später automatisch, entweder durch ein InternalTimer aufgerufen am Ende des Define oder was sich eher durch setzt durch ein abfangen des passenden globalen Events.
Welcher Event wäre denn wohl passend?
ZitatDas keepAlive kannst Du dann tatsächlich durch das dauerhafte aufrufen einer Funktion erreichen.
Wäre es besser, das in einem 2. Modul zu machen, um die FHEM Schleife nicht zu "überlasten"?
if( $cmd eq 'statusSOE' ) Danke! Den code habe ich getestet - läuft super, aber woher nimmst Du statusSOE?
Ich dachte erst, ich hätte irgend etwas in der Dev.Doku übersehen, aber auch eine google Suche mit "FHEM und statusSOE" bringt nichts zu Tage.
Danke für Deine Mühen!
Nee, Daten fließen da noch nicht.
Der Socket wurde ja noch nicht initialisiert.
Dann muß erst ein "Anmeldepaket" an den UDP Server des Deamons geschickt werden damit dieser sich den Port vom Modul einträgt und Daten auch dorthin sendet.
Weiß nur nicht, wo und wie ich das im code unterbringe?!? In meinem Testprogramm war es in einer Schleife... Ist in FHEM wohl keine gute Idee.
In meinem Testprogramm sieht das so aus:
#my $data = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
#$socket->send($data);
Das ist dann gleich den keep_alive Paketen, ohne die der Daemon das Senden wieder einstellt.
Das ist das Log mit Verbose im Modul auf 5:
2017.10.31 21:39:15 3: HCAN_Test (HCAN_Test) - device HCAN_Test deleted
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Undef redefined at ./FHEM/78_HCAN_Test.pm line 92.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Attr redefined at ./FHEM/78_HCAN_Test.pm line 107.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Set redefined at ./FHEM/78_HCAN_Test.pm line 120.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Open redefined at ./FHEM/78_HCAN_Test.pm line 178.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Close redefined at ./FHEM/78_HCAN_Test.pm line 219.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_ReOpen redefined at ./FHEM/78_HCAN_Test.pm line 236.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Write redefined at ./FHEM/78_HCAN_Test.pm line 250.
2017.10.31 21:39:40 1: PERL WARNING: Subroutine HCAN_Test_Read redefined at ./FHEM/78_HCAN_Test.pm line 275.
!!!Initialize
!!!Define
2017.10.31 21:40:13 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
if( $cmd eq 'connect' ) {
return Connect($hash);
} else {
my $list = 'connect:noArg';
return "Unknown argument $cmd, choose one of $list";
}
Mein Fehler, sorry. cmd eq muss mit dem übereinstimmen was unten im $list steht. $list ist das was als set Befehl angezeigt wird und $cmd eq das was akzeptiert wird.
Als Standard Log Level ist global 3 eingestellt. Es werden also nur Logausgaben angezeigt die in den Modulen 1 2 und 3 haben
Log3 $name, 5, "Modulname ($name) - ProcessingNotification";
Das hier z.B. st 5 und würde nicht angezeigt werden.
Am besten Du stellst Deine Logausgaben im Testmodul auf 3
Log3 $name, 3, "Modulname ($name) - ProcessingNotification";
Das keepAlive ist dafür da Deine Socketverbindung aufrecht zu erhalten. So habe ich es zu mindest verstanden. In meinen Augen ist es damit Bestandteil des physikalischen Modules. Also des Modules wo die Socketverbindung verwaltet wird.
Hier machst Du einfach eine Funktion welche ein syswrite macht und sich danach verzögert durch InternalTimer wieder selbst aufruft.
Zum Thema Notify
sub blablub_Initialize($) {
...
$hash->{NotifyFn} = "XiaomiFlowerSens_Notify";
...
}
...
sub blablub_Notify($$) {
my ($hash,$dev) = @_;
my $name = $hash->{NAME};
return if (IsDisabled($name));
my $devname = $dev->{NAME};
my $devtype = $dev->{TYPE};
my $events = deviceEvents($dev,1);
return if (!$events);
blablub_connect($hash) if( grep /^INITIALIZED$/,@{$events}
or (grep /^DEFINED.$name$/,@{$events} and $init_done) );
return;
}
INITIALIZED ist der globale Event wenn FHEM vollständig gestartet ist. DEFINED unteranderem wenn man ein modify macht.
Schau mal das Du erstmal Daten über die ReadFn bekommst. Wenn sich Deine Moduldatei nicht geändert hat muss in Deinem FHEM log
HCAN_Test ($name) - received buffer data, start VCLIENT_Test_ProcessRead: $buf
stehen und für $buf halt die Daten
kleinen Moment ich schaue mal das ich da was vor bereite
Das ist klasse. Ehrlich gesagt, habe ich grad fast nur Bahnhof verstanden. :'(
Wie gesagt, totaler FHEM & perl Anfänger.
Na ja, und wenn ich ehrlich bin, tue ich mich mit Objekten auch noch etwas schwer.
Als ich angefangen habe zu Programmieren, gab es noch keine Objektorientierung.
Dann hab ich Jahre Lang nix mehr gemacht, und jetzt hab ich den Salat! :-[
sub HCAN_Test_KeepAlive($) {
my $hash = shift;
my $data = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00';
HCAN_Test_Write($hash,$data);
InternalTimer( gettimeofday()+$hash->{INTERVAL}+30, "HCAN_Test_KeepAlive", $hash);
}
sub HCAN_Test_Write($@) {
print("!!!Write\n");
my ($hash,$data) = @_;
my $name = $hash->{NAME};
Log3 $name, 3, "HCAN_Test ($name) - WriteFn called";
return Log3 $name, 3, "HCAN_Test ($name) - socket not connected"
unless($hash->{CD});
Log3 $name, 3, "HCAN_Test ($name) - $data";
syswrite($hash->{CD}, $data);
return undef;
}
ub HCAN_Test_Open($) {
...
...
### ganz am Ende
HCAN_Test_KeepAlive($hash);
}
Und vergiss die 1;
am Ende der Moduldatei bitte nicht
Schau mal mal ob Du damit weiter kommst. Ist erstmal ohne große Prüfung.
Damit sollte nach dem Du ein set connect gemacht hast und somit ja die Connect Routine gestartet und die Socketverbindung aufgebaut wurde die Routine KeepAlive gestartet werden, welche sich am Ende wieder selbst auf rufst aber durch InternalTimer 30s verzögert.
Wahnsinn, ist das für Dich eigentlich so wie eine Mail zu schreiben?
Also: Es geht noch nicht vollständig, ich wollte Dir aber schonmal den Zwischenstand mitteilen:
Erst kam das:
!!!Initialize
!!!Define
2017.10.31 22:17:50 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
!!!Set
!!!Set
!!!Set
Undefined subroutine &main::Connect called at ./FHEM/78_HCAN_Test.pm line 128.
Dann habe ich Zeile 128 von "return Connect($hash);" auf "return HCAN_Test_Open($hash);" geändert.
Dann gibt es eine Warnung:
PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/78_HCAN_Test.pm line 256
Ich vermute, das liegt an der addition von undef mit 30 für den Timer?!?
InternalTimer( gettimeofday()+$hash->{INTERVAL}+30, "HCAN_Test_KeepAlive", $hash);
Seit dem kommt:
!!!Initialize
!!!Define
2017.10.31 22:26:12 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
!!!Set
!!!Write
2017.10.31 22:26:24 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:26:24 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Write
2017.10.31 22:26:26 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:26:26 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Set
!!!Open
2017.10.31 22:26:30 4: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.10.31 22:26:30 4: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.10.31 22:26:30 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:26:30 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
!!!Set
!!!Set
!!!Set
!!!Write
2017.10.31 22:26:54 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:26:54 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Write
2017.10.31 22:26:56 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:26:56 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Write
2017.10.31 22:27:00 3: HCAN_Test (HCAN_Test) - WriteFn called
2017.10.31 22:27:00 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Er öffnet den Socket hält ihn dann auch offen, jedoch zeigt er keine eingehenden Pakete.
Kann es sein, dass er damit nix anfangen kann. In meinem Test-Programm muß ich die noch in hex wandeln:
print unpack("H*", $incommming),"\n";
Der String der gesendet wird stimmt aber? Er muss also genau so aussehen?
Und die empfangenen Daten müssen dann noch in Hex umgewandelt werden?
Aber dennoch muss er ja irgendwas empfangen.
Hänge Mal bitte deine aktuelle Moduldatei hier an. Ich gehe jetzt schlafen aber würde Mal morgen früh das Modul soweit schreiben das ein ständiges keepAlive gesendet wird.
Teste dann das Modul auch das es sauber läd. Passen denn 30s Interval für das KeepAlive?
Der String sollte passen. (16mal \x00) Den sende ich ein meinem hcan2.pl auch.
Ich mache nochmal einen Dump vom hash innerhalb von _write. Auch wenn es vermutlich nix bringt.
Die Emfpangenen Daten habe ich in hex umgewandelt. Sonst kamen nur wilde Sonderzeichen.
Die 30 Sekunden sollten gefühlt passen. Sind vermutlich ehr zu "kurz" als zu lang. Ich habe da leider genauen Zeiten. Da müßte ich mal den Quellcode vom Daemon durchforsten.
Auf jeden Fall beobachte ich den Daemon mit einem anderen UDP Client. Der sendet munter vor sich hin. Auch kurz nachdem im Log grad angezeigt wird, dass das keep_alive frame gesendet wurde.
Es taucht aber trotzdem nichts Empfangenes auf.
Vielleicht ist genau das das Problem. Das da noch ein anderer Client mit dran klebt. Mach mal nur dein Modul eine Verbindung aufbauen und sonst nichts anderes.
Nee, das sollte kein Problem sein. Ich hatte, als ich mit meinem perl Modul experiemtiert habe, auch noch den "original" telican client mitlaufen. Genau wie jetzt auch. Ich versuche es noch mal ohne den 2. Client. Schreibe Dir dann was es gegeben hat und hänge den aktuellen Coden an.
Vielen Dank nochmals & eine gute Nacht - ohne FHEM Träume ;)
Also, ich habe nochmals folgendes gemacht:
1. den $hash gedumpt, das ist die Ausgabe:
!!!Define
2017.10.31 23:03:27 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
!!!Write
2017.10.31 23:03:30 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: ';
2017.10.31 23:03:30 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Set
!!!Open
2017.10.31 23:03:36 4: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.10.31 23:03:36 4: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.10.31 23:03:36 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0x9ffc4dc)';
2017.10.31 23:03:36 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
!!!Set
!!!Set
!!!Set
!!!Write
2017.10.31 23:03:50 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: ';
2017.10.31 23:03:50 3: HCAN_Test (HCAN_Test) - socket not connected
!!!Write
2017.10.31 23:03:51 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: ';
2017.10.31 23:03:51 3: HCAN_Test (HCAN_Test) - socket not connected
Den Dump habe ich im angehangenen Quellcode belassen, dann sieht Du wo er eingefügt ist.
2. Habe ich den "Kontroll"-UDP Client beendet, und alles neu gestertet.
Wie vermutet, werden trotzdem im Log keine Pakete angezeigt.
In der Doku zum Daemon steht auch, dass er "Mulit-Client" fähig ist. Er trägt sich den Port jedes Clients nach dem ersten Connect durch den Client ein, und sendet die Daten dann auch an den Client-Port.
Bzgl. der Zeiten, nach denen der Daemon den Versand an den Client unterbricht und auf ein Keep Alive Paket wartet, müßte ich noch mal suchen.
Wenn die Kontaktaufnahme über ein physiches Modul läuft, wäre doch auch das Try/Catch konstrukt aus meinem Perl-Client (hcan2.pl) möglich - oder?!?
Das wäre dann IMHO die Sauberste Lösung. So würde er sich ja neu verbinden, sobald der Socket down ist und nichts geht verloren.
Vielen Dank nochmals für Deine Hilfe!
Gute Nacht!
Guten Morgen,
Eigentlich passt bei Deinem Modul soweit alles was ich gesehen habe. Ein zwei Sachen habe ich mal hinzu gefügt und auch was weg genommen. Vorerst. Unter anderem dem Type der Socketverbindung, also ob Stream oder Datagramm.
Mal schauen was er draus macht. Und das unpack habe ich mal in die Read mit eingebaut.
Probiere bitte einfach mal erstmal so und was dann im fhem log steht bräuchte ich bitte einmal.
Ebenfalls Guten Morgen!
Ich hatte noch nicht mit Dir gerechnet! ;)
Ich habe mir mal mit tcpdump die Pakete angesehen, die unterwegs sind. Aus FHEM wird nix versendet. Das Log schreibt zwar:
2017.11.01 08:05:02 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0x97b7b74)';
2017.11.01 08:05:02 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Aber es sind keine Paket von FHEM auf localhost zu sehen.
Werde das Programm mit Deinen Änderungen aber trotzdem mal ausführen.
Nee, leider immer noch keine Pakete vom FHEM.
Ich habe in meinem Testprogramm DGRAM verwendet, wird im "original" hcan Tool ebenfalls verwendet - muß also damit gehen.
Soll ich den Quellcode von Gestern wieder aktivieren, oder den von Dir gesendeten umstellen auf DGRAM.
Frage nur, damit wir die gleichen Versionen haben.
Falls du möchtest, könnte ich dir zum Testen den hcand und telican senden. Die sollten unabhängig vom Bus laufen, und alle ca. 60 sek. Zeit und Datum Pakete per UDP senden. Ich würde natürlich vorher probieren, ob die wirklich ohne Bus lauffähig sind...
Falls ja, müßtest Du nur "hcand & telican --timed &" aufrufen und könntest in einem 2. Fenster mit telican -d den Dump der UDP Pakete zur Kontrolle sehen.
Ich muß jetzt kurz `ne Milch für unsere Kinder zaubern. Bin gleich zurück...
Viel habe ich ja nicht geändert. Können die aktuelle gerne belassen. Das mit dem Type kannst ja einfach wieder einbauen.
Und Dein pl File hat funktioniert? also dort konntest Du Daten an den Bus senden und auch empfangen?
Möglich das ich einen Fehler gefunden habe. Moment
Probiere mal bitte damit
Nee, leider immer noch nicht.
Habe den Typ auch wieder auf Datagram gestellt, leider ebenfalls nix.
och menno,
Noch mal die Frage. Das pl hatte aber funktioniert sagst?
Vielleicht hat es was damit zu tun das es udp ist. Aber das muß ich wenn auch erst nach schauen.
Ich habe das hcan2.pl die ganze Zeit parallel mitlaufen gehabt.
Es gibt mir auf der Konsole die hcan Frames als HEX aus.
Ich sehe im tcpdump auch die keep_alive Pakete:
09:19:01.879164 IP localhost.35554 > localhost.3600: UDP, length 16
0x0000: 4500 002c be53 4000 4011 7e6b 7f00 0001
0x0010: 7f00 0001 8ae2 0e10 0018 fe2b 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000
Nur vom FHEM is nix zu sehen.
Hab die Parameter nochmals überprüft. Ich kann nichts entdecken.
Hier nochmal der Ablauf:
########### MODUL RELOAD: reload 78_HCAN_Test
!!!Initialize
########### MODUL DEFINE: define HCAN_Test HCAN_Test localhost
!!!Define
2017.11.01 09:41:09 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
################### KLICK AUF SET HCAN_Test CONNECT
!!!Set
!!!Open
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xabd8fb8)';
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 09:41:37 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/78_HCAN_Test.pm line 256.
Habe gerade gesehen das in der KeepAlive Funktion beim InternalTimer Aufruf noch ein Fehler ist. $hash->INTERVAL muß raus. Da darf nur +30 stehen.
Aber das wird es nicht sein.
und wenn Du das pl Script aus lässt kommt bei FHEM auch nichts an?
Ah, dann war das der Grund für die Warnung von perl.
Ich habe gestern Abend noch alle tools außer FHEM beendet. Trotzdem kein Verbindung.
Hab grad nochmals die offenen Ports überprüft. Also, so bald ich auf set connect klicke, habe ich einen UDP Port mehr.
Das scheint also soweit zu funktionieren.
Fragt sich nur, warum er die Daten nicht heraus bekommt.
Vor allem klappt ja laut Deiner Aussage das syswrite auch nicht.
Nimm mal das hier und gib mir dann mal bitte nach 1min das log
Gerne, anbei das Log:
!!!Initialize
!!!Define
2017.11.01 10:58:33 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
!!!Set
!!!Open
2017.11.01 10:58:40 3: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.11.01 10:58:40 3: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.11.01 10:58:40 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xa757c38)';
2017.11.01 10:58:40 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 10:58:40 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/78_HCAN_Test.pm line 255.
!!!Write
2017.11.01 10:59:10 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xa757c38)';
2017.11.01 10:59:10 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
!!!Write
2017.11.01 10:59:40 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xa757c38)';
2017.11.01 10:59:40 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 10:59:55 3: FHEMWEB WEB CSRF error: csrf_201500400611968 ne csrf_343132966347035 for client WEB_127.0.0.1_47219. For details see the csrfToken FHEMWEB attribute.
!!!Write
2017.11.01 11:00:10 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xa757c38)';
2017.11.01 11:00:10 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
^C
Ich habe eine böse Ahnung.
Mal gaaanz vorsichtig gefragt, Du machst nach dem einspielen der neuen Moduldatei oder des neuen Inhaltes in die Moduldatei schon noch ein reload??
Ich mache es so wie hier:
Zitat von: GU!DO am 31 Oktober 2017, 18:08:33
Grundsätzlich gehe ich folgender Maßen vor, wenn ich Änderungen am Modul gemacht habe:
1. Ich lösche das Test-Device.
2. ich mache einen Reload des Moduls mit reload...
3. ich Erstelle ein neues Device mit define...
Ich denke das ist so ok?!
und hier:
Zitat von: GU!DO am 01 November 2017, 09:49:40
Hier nochmal der Ablauf:
########### MODUL RELOAD: reload 78_HCAN_Test
!!!Initialize
########### MODUL DEFINE: define HCAN_Test HCAN_Test localhost
!!!Define
2017.11.01 09:41:09 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
################### KLICK AUF SET HCAN_Test CONNECT
!!!Set
!!!Open
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xabd8fb8)';
2017.11.01 09:41:37 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 09:41:37 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/78_HCAN_Test.pm line 256.
beschrieben. Ist das Flasch?!?
Es fehlen Log Ausgaben und die Fehlermeldung undefined bla bla dürfte auch nicht mehr kommen.
Hier mal der komplette aktuelle Code
package main;
use strict;
use warnings;
use IO::Socket::INET;
# zum Debuggen
use Data::Dumper;
#my $missingModul = "";
#eval "IO::Socket::INET" or $missingModul .= "IO::Socket::INET";
my $version = "0.0.1";
####################################
# Wird zur Initialisierung beim ersten Laden des Moduls in FHEM
# aufgerufen
#
sub HCAN_Test_Initialize($) {
print("!!!Initialize\n");
my ($hash) = @_;
$hash->{ReadFn} = "HCAN_Test_Read";
$hash->{WriteFn} = "HCAN_Test_Write";
$hash->{SetFn} = "HCAN_Test_Set";
$hash->{DefFn} = "HCAN_Test_Define";
$hash->{UndefFn} = "HCAN_Test_Undef";
$hash->{AttrFn} = "HCAN_Test_Attr";
$hash->{AttrList} = $readingFnAttributes;
foreach my $d(sort keys %{$modules{HCAN_Test}{defptr}}) {
my $hash = $modules{HCAN_Test}{defptr}{$d};
$hash->{VERSION} = $version;
}
}
#####################################
# wird aufgerufen wenn der Define-Befehl für ein Geräte ausgeführt wird und das
# Modul bereits geladen und mit der Initialize-Funktion initialisiert ist
#
# übergebene Parameter prüfen und an geeigneter Stelle speichern-
# sowie einen Kommunikationsweg zum Gerät öffnen
#
sub HCAN_Test_Define($$) {
print("!!!Define\n");
my ( $hash, $def ) = @_;
my @a = split( "[ \t][ \t]*", $def );
return "too few parameters: define <name> HCAN_Test <HOST> " if( @a != 3 );
# return "Cannot define a HCAN device. Perl modul $missingModul is missing." if ( $missingModul );
my $name = $a[0];
my $host = $a[2];
$hash->{HOST} = $host;
$hash->{VERSION} = $version;
Log3 $name, 3, "HCAN_Test ($name) - defined with host $host";
$attr{$name}{room} = "HCAN_Test" if( !defined( $attr{$name}{room} ) );
$attr{$name}{verbose} = "5";
readingsBeginUpdate($hash);
readingsBulkUpdate($hash,'state','Initialized');
readingsEndUpdate($hash,1);
$modules{HCAN_Test}{defptr}{$host} = $hash;
return undef;
}
#####################################
# Wird im Rahmen des delete-Befehls, sowie rereadcfg-Befehl aufgerufen.
# Dient zum Abbau von offenen Verbindungen, Timern, etc.-
#
sub HCAN_Test_Undef($$) {
print("!!!Undef\n");
my ( $hash, $arg ) = @_;
my $host = $hash->{HOST};
my $name = $hash->{NAME};
RemoveInternalTimer($hash);
HCAN_Test_Close($hash);
delete $modules{HCAN_Test}{defptr}{$hash->{HOST}};
Log3 $name, 3, "HCAN_Test ($name) - device $name deleted";
return undef;
}
sub HCAN_Test_Attr(@) {
my ( $cmd, $name, $attrName, $attrVal ) = @_;
my $hash = $defs{$name};
my $orig = $attrVal;
return undef;
}
#####################################
# Wird im Rahmen des set-Befehls aufgerufen um Daten an das Gerät zu senden.
#
sub HCAN_Test_Set($@) {
print("!!!Set\n");
my ($hash, $name, $cmd, @args) = @_;
my ($arg, @params) = @args;
if( $cmd eq 'connect' ) {
return HCAN_Test_Open($hash);
} else {
my $list = 'connect:noArg';
return "Unknown argument $cmd, choose one of $list";
}
# # my $telnetCmd;
# # $cmd = 'connect' if $cmd == '?';
# print Dumper('Dumper: '.$cmd);
#
#
# if($cmd eq 'reconnect') {
# return "usage: $cmd" if( @args != 0 );
#
# HCAN_Test_ReOpen($hash);
# return undef;
#
# } elsif($cmd eq 'connect') {
# return "usage: $cmd" if( @args != 0 );
#
# HCAN_Test_Open($hash);
# return undef;
#
# } elsif($cmd eq 'disconnect') {
# return "usage: $cmd" if( @args != 0 );
#
# HCAN_Test_Close($hash);
# return undef;
#
# } elsif($cmd eq 'sendCmd') {
#
# # $telnetCmd = $arg;
#
# } else {
#
# my $list = "";
# $list .= "reconnect:noArg connect:noArg disconnect:noArg";
# return "Unknown argument $cmd, choose one of $list";
# }
#
# HCAN_Test_Write($hash,$telnetCmd);
}
########################################
# Oeffnet den Socket
# Schreibt die Verbindungsdaten für %select in den hash
#
sub HCAN_Test_Open($) {
print("!!!Open\n");
my $hash = shift;
my $name = $hash->{NAME};
my $host = $hash->{HOST};
my $port = 3600;
my $timeout = 0.1;
Log3 $name, 3, "HCAN_Test ($name) - Baue Socket Verbindung auf";
my $socket = new IO::Socket::INET ( PeerHost => $host,
PeerPort => $port,
Proto => 'udp',
Timeout => $timeout,
Type => SOCK_DGRAM
)
or return Log3 $name, 3, "HCAN_Test ($name) Couldn't connect to $host:$port";
$hash->{FD} = $socket->fileno();
$hash->{CD} = $socket; # sysread / close won't work on fileno
$selectlist{$name} = $hash;
readingsSingleUpdate($hash, 'state', 'connected', 1 );
Log3 $name, 3, "HCAN_Test ($name) - Socket Connected";
# "Anmelde" Paket senden
HCAN_Test_KeepAlive($hash);
}
########################################
# Schließt den Socket
# Loescht die Verbindungsdaten im hash
#
sub HCAN_Test_Close($) {
print("!!!Close\n");
my $hash = shift;
my $name = $hash->{NAME};
return if( !$hash->{CD} );
close($hash->{CD}) if($hash->{CD});
delete($hash->{FD});
delete($hash->{CD});
delete($selectlist{$name});
readingsSingleUpdate($hash, 'state', 'not connected', 1 );
RemoveInternalTimer($hash);
}
sub HCAN_Test_ReOpen($) {
my $hash = shift;
my $name = $hash->{NAME};
HCAN_Test_Close($hash);
HCAN_Test_Open($hash) if( !$hash->{CD} or !defined($hash->{CD}) );
}
########################################
# Keep Alive
#
sub HCAN_Test_KeepAlive($) {
my $hash = shift;
my $data = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00';
HCAN_Test_Write($hash,$data);
InternalTimer(gettimeofday()+30, "HCAN_Test_KeepAlive", $hash);
}
########################################
# wird durch die Funktion IOWrite() aufgerufen, sobald eine logische
# Geraetefinition Daten per IO-Gerät an die Hardware übertragen moechte
#
sub HCAN_Test_Write($@) {
print("!!!Write\n");
my ($hash,$data) = @_;
my $name = $hash->{NAME};
Log3 $name, 3, "HCAN_Test ($name) - WriteFn called";
print Dumper('Dumper: '.$hash->{CD});
return Log3 $name, 3, "HCAN_Test ($name) - WriteFn socket not connected"
unless($hash->{CD});
Log3 $name, 3, "HCAN_Test ($name) - $data";
my $resp = syswrite($hash->{CD}, $data);
Log3 $name, 3, "HCAN_Test ($name) - Write Response: $resp";
return undef;
# my ($hash,$string) = @_;
# my $name = $hash->{NAME};
#
#
# $string .= "\r\n";
# Log3 $name, 4, "HCAN_Test ($name) - WriteFn called";
#
# return Log3 $name, 4, "HCAN_Test ($name) - socket not connected"
# unless($hash->{CD});
#
# Log3 $name, 5, "HCAN_Test ($name) - $string";
# syswrite($hash->{CD}, $string);
#
# return undef;
}
#####################################
# called from the global loop, when the select for hash->{FD} reports data
# Wird durch FHEM aufgerufen, wenn ein gelisteter Filedeskriptor in %selectlist
# Daten zum Lesen bereitstellt.
#
sub HCAN_Test_Read($) {
print("!!!Read\n");
my $hash = shift;
my $name = $hash->{NAME};
my $len;
my $buf;
Log3 $name, 4, "HCAN_Test ($name) - ReadFn gestartet";
#$len = sysread($hash->{CD},$buf,1024);
$len = sysread($hash->{CD},$buf,1500);
Log3 $name, 3, "HCAN_Test ($name) - Daten Empfangen. Länge: $len - Daten: " . unpack('H*', $buf);
if( !defined($len) || !$len ) {
Log3 $name, 3, "HCAN_Test ($name) - connection closed by remote Host";
HCAN_Test_Close($hash);
return;
}
unless( defined $buf) {
Log3 $name, 3, "HCAN_Test ($name) - no data received";
return;
}
Log3 $name, 3, "HCAN_Test ($name) - received buffer data, Data: $buf";
readingsSingleUpdate($hash,'response',$buf,1);
}
######################################
# FHEM zeigen, dass alles o.k. ist
1;
Der Weg an sich ist auf jefen Fall korrekt. Du kannst auch mal die version ändern, das sollte dann auch gleich im INTERNAL zu sehen sein.
Um ganz sicher zu gehen, habe ich den FHEM Prozess zwischen dem löschen des vorhanden Test-Devices und dem reload teilweise auch beendet und neu gestartet.
Nimm mal bitte die hier. Und dann gibst Du mir bitte eine Logausgabe und eine Ausgabe von
list DEVICENAME
Versuch ich sofort. Ich habe in der Zwischenzeit nochmal folgendes probiert:
(Ist quick an dirty, aus meinen bisherigen Versuchen kopiert.)
Wenn ich das ausführe, bekomme ich mittels TCP Dump das "keep_alive" Paket und den nachfolgenden Befehl auf dem Bus angezeigt.
1. Eingefügt:
use Socket;
2. _Write habe ich geändert,
1 sub HCAN_Test_Write($@) {
2 print("!!!Write\n");
3 my ($hash,$data) = @_;
4 my $ret=HCAN_Test_Send($hash);
5 return undef;
6 }
und 3. dieses angefügt.
1 sub HCAN_Test_Send($$){
2 my ($hash,$HEX)=@_;
3 my $trans_serv = getprotobyname( 'udp' );
4 my $remote_host = gethostbyname( REMOTE_HOST );
5 my $remote_port = SIMPLE_UDP_PORT; my $destination = sockaddr_in( $remote_port, $remote_host );
6
7
8 socket( UDP_SOCK, PF_INET, SOCK_DGRAM, $trans_serv );
9
10 # Keep-Alive-Paket senden
11 my $data = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
12 send( UDP_SOCK, $data, 0, $destination );
13 # Daten senden
14 my $data = "\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0b\x32\xb7\xec\x3a\x6f\xb7";
15 send( UDP_SOCK, $data, 0, $destination );
16 select(undef, undef, undef, 0.3); #pause 0.3 seconds
17 Log3 $hash->{NAME}, 5, 'Gesendet! ';
18 return undef;
19 }
Werde jetzt direkt Deins probieren...
AHHH SORRY, SORRY, SORRY... WO IST DAS SYMBOL, BEI DEM DER TYP DEN KOPF GEGEN DIE WAND HAUT!!!!!
Es tut mir wirklich leid. Ich weiß, warum Deine Änderungen nicht übernommen wurden.
Ich habe hier diese Downloads:
Nov 1 09:05 /root/Downloads/78_HCAN_Test(1).pm
Nov 1 10:54 /root/Downloads/78_HCAN_Test(2).pm
Nov 1 11:42 /root/Downloads/78_HCAN_Test(3).pm
Nov 1 08:06 /root/Downloads/78_HCAN_Test.pm
hab aber zum Kopieren immer:
/../Downloads/78_HCAN_Test.pm guido@10.20.30.115:/home/guido
aus der Shell-History ausgeführt.
TUT MIR WIRKLICH LEID, DASS ICH DAMIT DEINE ZEIT VERGÄUDET HABE. SORRY!!!
Test das letzte Modul direkt.
Habs getestet, er sendet:
11:52:15.250168 IP localhost.54675 > localhost.3600: UDP, length 64
0x0000: 4500 005c faf2 4000 4011 419c 7f00 0001
0x0010: 7f00 0001 d593 0e10 0048 fe5b 5c78 3030
0x0020: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0030: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0040: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0050: 5c78 3030 5c78 3030 5c78 3030
Ich hoffe Du spricht jetzt noch mit mir?!? :-[
;D
Dachte mir schon das da irgendwas nicht ganz sauber ist. Nicht wild. Ich bin manchmal nicht besser.
Aber jetzt müssen wir uns mal sortieren. Also er sendet das keepAlive nun auf den Bus. Nun geht es noch darum ob er auch empfängt.
Was sagt das fhem Log
Grüße
Danke für das Verständniss. Ich glaube ich hab mal was vom Berliner Stammtisch und `nem Bierchen gelesen. Wenn Berlin nur nicht so weit von Münster entfernt wäre...
Hab mir den Code noch nicht ansehen könne, da meine Frau mich zwischendurch immer Einspannt...
Also, das Paket ist noch zu Groß. 64 zu den geforderten 16. Das gibt Mecker vom hdan Daemon. Aber das sollte ja nicht das Problem sein.
Anbei das Log schaut vielversprechend aus:
!!!Initialize
!!!Define
2017.11.01 11:51:51 3: HCAN_Test (HCAN_Test) - defined with host localhost
!!!Set
!!!Set
!!!Set
!!!Set
!!!Set
!!!Open
2017.11.01 11:52:02 3: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
2017.11.01 11:52:02 3: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.11.01 11:52:02 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0xa7da584)';
2017.11.01 11:52:02 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 11:52:02 3: HCAN_Test (HCAN_Test) - Write Response: 64
!!!Set
!!!Set
!!!Set
!!!Set
!!!Open
2017.11.01 11:52:15 3: HCAN_Test (HCAN_Test) - Baue Socket Verbindung auf
!!!Set
!!!Set
2017.11.01 11:52:15 3: HCAN_Test (HCAN_Test) - Socket Connected
!!!Write
2017.11.01 11:52:15 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0x9be3664)';
2017.11.01 11:52:15 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 11:52:15 3: HCAN_Test (HCAN_Test) - Write Response: 64
!!!Set
!!!Set
!!!Set
!!!Write
2017.11.01 11:52:32 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0x9be3664)';
2017.11.01 11:52:32 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 11:52:32 3: HCAN_Test (HCAN_Test) - Write Response: 64
!!!Write
2017.11.01 11:52:45 3: HCAN_Test (HCAN_Test) - WriteFn called
$VAR1 = 'Dumper: IO::Socket::INET=GLOB(0x9be3664)';
2017.11.01 11:52:45 3: HCAN_Test (HCAN_Test) - \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
2017.11.01 11:52:45 3: HCAN_Test (HCAN_Test) - Write Response: 64
!!!Read
2017.11.01 11:53:00 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.01 11:53:00 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 2490100307000000060100030b3500b7
2017.11.01 11:53:00 3: HCAN_Test (HCAN_Test) - received buffer data, Data: $�
Das Kauderwelsch aus der letzten Zeille (hier nur zum Teil zu sehen) müsste noch in HEX umgewandelt werden.
2017.11.01 11:53:00 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.01 11:53:00 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 2490100307000000060100030b3500b7
So da haste Deine Daten ;D Er empfängt also. Ob das mit dem write Response 64 jetzt falsch ist kann ich nicht sagen. Aber er sendet und er empfängt nun schon mal. Schritt eins von 99 erledigt!
Mal davon ab,
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Sind bei mir 64 Zeichen.
Zitat2017.11.01 11:53:00 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.01 11:53:00 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 2490100307000000060100030b3500b7/
Ups, da hab ich doch das Wesentliche übersehen.
ZitatSchritt eins von 99 erledigt!
Na Du machst mir ja Mut!
Hmm, also er soll schon Pakete mit einer Größe von 16 Bytes bekommen... und die hat der mit meinem hcan2.pl und gleichem Code auch so gesendet:
tcpdump Ausgabe vom hcan2.pl:
12:22:17.085751 IP localhost.47240 > localhost.3600: UDP, length 16
0x0000: 4500 002c a5af 4000 4011 970f 7f00 0001
0x0010: 7f00 0001 b888 0e10 0018 fe2b 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000
tcpdump Ausgabe vom fhem Paket:
12:00:02.285332 IP localhost.54675 > localhost.3600: UDP, length 64
0x0000: 4500 005c 0a33 4000 4011 325c 7f00 0001
0x0010: 7f00 0001 d593 0e10 0048 fe5b 5c78 3030
0x0020: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0030: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0040: 5c78 3030 5c78 3030 5c78 3030 5c78 3030
0x0050: 5c78 3030 5c78 3030 5c78 3030
Er sagt ja auch, Length 16 zu Length 64.
Probiere mal bitte
So, wie war das noch mit dem blinden Huhn...
Habe den HEX String in doppelte Anführungszeigen gepackt, da er sonst meinte, er müsse den "\" Escapen. Im Dump sah das dann so aus:
$VAR1 = 'Write: \\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00';
Jetzt sendet er 16 Bytes.
Auf die selbe Idee bin ich auch gekommen. Hab ich im File oben so angepasst. hihi
Also in Version 0.0.25 schreibt er nun alle 30s ein keepalive und empfängt an sonsten die Daten über die Read. Korrekt?
Hab mir Grad Deine Datei angesehen.
Das unterschiedet den Wissenden vom Anfänger. Du machst das dann mal einfach so...
Hattest du sonst noch was geändert?
Ich überlege schon seit längerem, wie man das Ganze am besten in Module gießt.
Das System sieht folgender Maßen aus:
Jedes Device ist einer oder mehreren Gruppen zugeordnet.
Die Gruppen sind Device Spezifisch. Wenn also z.B. eine Gruppe 70 Powerport geschaltet wird, reagieren nur die Powerport Devices, in deren Gruppenkonfiguration eine 70 eingetragen ist. Ein Rolladendevice, welches evtl. ebenfalls auf Gruppe 70 konfiguriert ist, nicht, sondern erst, wenn Rolladen 70 gesendet wird.
Folgende Geräte die am Bus betrieben werden, wären IMHO in FHEM interessant:
Aktoren
Powerports (die steuern einfach nur ein Relais, welches z.B. eine Lampen einschatet)
Rolladen (2 Relais, EIN/AUS und Richtung werden vom Controller gesteuert. 100%=ganz hoch. Würde dann z.B. mit Position-Set 100 angestoßen werden)
Heizungs-Stellmotor: im Prinzip wie der Rolladen 0-100%
Sensoren
Tempsensor liest Temperaturen aus DS1820 Temperatursensoren
Reedkontakt ueberwacht einen Kontakt, typischerweise ein Reed-Kontakt
Helligkeitssensor Sendet Helligkeitssensornachrichten auf den CAN-Bus
Ich hatte mir folgendes überlegt:
2 Physische Module:
1. wenn möglich mit try/catch Schleife zum mithören der Befehle auf dem Bus.
Hex Daten werden ausgewertet, und an das jeweils Zuständige logische Device weiter gereicht
2. um Daten an den Bus zu senden
Für jedes Device ein logisches Modul, das
- die jeweiligen Parameter zur Verfügung stellt. Also z.B. Ein/Aus bei Powerport, oder 0-100% bei Rolladen & Heizung.
- die Werte der Sensoren anzeigt. Wie Temperatur, Kontakt offen/geschlossen oder die aktuelle Helligkeit
Was hälst Du davon, bzw. wie würdest Du als nächstes vorgehen?
Zitat von: CoolTux am 01 November 2017, 13:12:53
Also in Version 0.0.25 schreibt er nun alle 30s ein keepalive und empfängt an sonsten die Daten über die Read. Korrekt?
Yep. Das ist korrekt.
Muß mich mal kurz um meine Kinder kümmern. Bin in ca. 45 Min. wieder am Rechner.
Nochmals: Vielen Dank für Deine Ausdauer!!!
Zwei physische Devices ist Unsinn. Du machst ein physisches Modul welches die Verbindung zum Bus hat und ein logisches Modul (oder 2 logische Aktor Sensor). Unterscheiden tust Du Aktor, Sensor und ob Rolladen oder Lichtschalter mit Hilfe von Attributen. subType zum Beispiel.
Wichtig ist das Du weißt wie Du Rolladenaktor, Sensoren und Aktoren(Lichtschalter) von den empfangenden Telegrammen unterscheiden kannst. Denn irgendwas wird gebraucht um das zu unterscheiden. Desweiteren wird eine einmalige ID oder was anderes einmaliges benötigt was den Aktor/Sensor beschreibt.
Ich habe sowas noch nie gebaut.
Wenn ich nur ein physisches Modul mache, verpasse ich doch während des Sendens evtl. Daten auf dem Bus.
Der Daemon sendet ja muter drauf los, dem ist doch völlig egal, ob ich grad "zuhöre" oder nicht.
Die Zuordung der Pakete habe ich mir grad angesehen.
Ich kann Anhand der Datenpakete im Hex-Format unterscheiden, welches Device mit welche Gruppe gemeint ist.
Empfangenes Hex Paket:
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
^^ ^^ ^^ ^^
von links nach rechts:
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation. (z.B. Taster_Down/Up, Power_Group_On/Off ...)
Es gibt noch weitere Gruppen, in Gruppe 01 z.B. sind Nachrichten zur Erreichbarkeit und Uptime der Controller-Bords. (Vielleicht für später interessant)
11 = Power_Group_State_Info (Hier könnte auch Power_Group_ON/OFF als Befehl kodiert mit 0a/0b stehen)
46 = Gruppe 70
01 = Status EIN / 00 = Status AUS
d.h. unsere Lampe im Hausflur (die hängt am Powerport der auf Gruppe 70 hört) ist eingeschaltet worden.
Es gibt eine installation.xml Datei, in der man den Gruppen Namen zuordnen kann. Bei mir z.B. 70 LichtFlur.
Ich bin mir jedoch noch nicht im klaren, wie ich das am besten in FHEM Abbilde. Meine erste Idee war:
Ich habe ein Logisches Modul Lampe.
Dieses hat die Schaltzustände AN/AUS.
Bei beim Define dieses logischen Moduls lese ich alle Lampen Bezeichnungen inkl. der zugehörigen Gruppen aus der Datei installation.xml.
Dann bekommt der Benutzer eine Liste mit allen Lampen im System in den Attributen zur Auswahl angezeigt und kann sich entscheiden, welche Gruppe gesendet werden soll.
Nun sagtst Du, ein logisches Device für alle Aktoren. Aber jeder Aktor hat doch verschiedene Zustände. Ich muß also irgendwie zusehen, dass bei einer Lampe nicht Geöffnet/Geschlossen als Zustand auswählbar ist
Erstmal eins nach dem anderen.
FHEM kann senden und empfangen gleichzeitig. Das ist kein Problem.
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
Woran erkennst du am Telegramm das es deine Lampe im Hausflur ist und nicht die Lampe im Wohnzimmer?
Waran erkennst du das es eine Lampe und kein Sensor ist?
Diese Info brauchen wir erstmal. Basierend darauf unterscheiden wir dann ob Lampe oder Rolladenaktor oder Tempsensor und auch welches Device, ob Lampe Flur vorne oder Tempsensor Kinderzimmer und so weiter.
Das müssen wir erstmal klären.
Vielleicht noch etwas Grundsätzliches zum openHCAN System:
- Es besteht aus Controllern mit ATMega32 (oder 644) Prozessoren.
- Jeder Controller hat eine Adresse unter der er angesprochen werden kann, um ihn zu konfigurieren bzw. Firmwareupdates einzuspielen.
Diese Adresse ist nur zur Wartung interessant. Im Betrieb hat sie keine Funktion.
- Jeder (meiner) Controller hat 8 physische Ein- und 20-Ausgänge. Die den auf ihm konfigurierten "logischen" Devices zugeordnet werden können.
z.B.:
Device Taster: Belegt einen physischen Eingang und kann eine logische Adresse schalten.
Device Powerport: Kann mit einem physischen Ausgang (der z.B. ein Relais schaltet) verknüpft werden und mit bis zu 5 logischen Gruppen auf die er reagiert.
Device Rolladen: Muß mit 2 physichen Ausgängen verknüpft werden (1x Relais EIN/AUS & 1x Relais Auf/AB) und hat ebenfalls bis zu 5 logisch Gruppen.
Welches Relais wann schaltet, regelt das Rolladen Device selbstständig.
Die Daten innerhalb der Pakete:
Zitat von: GU!DO am 01 November 2017, 16:43:54
Empfangenes Hex Paket:
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
^^ ^^ ^^ ^^
von links nach rechts:
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation. (z.B. Taster_Down/Up, Power_Group_On/Off ...)
Es gibt noch weitere Gruppen, in Gruppe 01 z.B. sind Nachrichten zur Erreichbarkeit und Uptime der Controller-Bords. (Vielleicht für später interessant)
11 = Power_Group_State_Info (Hier könnte auch Power_Group_ON/OFF als Befehl kodiert mit 0a/0b stehen)
46 = Gruppe 70
01 = Status EIN / 00 = Status AUS
d.h. unsere Lampe im Hausflur (die hängt am Powerport der auf Gruppe 70 hört) ist eingeschaltet worden.
Die Paare 9-12 aus dem Paket enthalten die oben beschriebenen Daten.
ZitatWoran erkennst du am Telegramm das es deine Lampe im Hausflur ist und nicht die Lampe im Wohnzimmer?
Jedem Raum ist bei mir eine Gruppe zugeordnet. Gruppe 70(-79) ist unser Hausflur
Ich habe Gruppen im EG von 10(Küche)-80(GästeWC) und im
OG von 110(Bad) bis 160(Ankleide).
Die Gruppennummern dürfen sich überschneiden, da das System nicht nur die Gruppe, sondern auch das "Kommando" mit Berücksichtigit.
Also Powerport Gruppe 60 würde keinen Raffstore der eine Gruppe 60 eingetragen hat ansteuern.
Gruppe 60(-69): Büro ist vielleicht ein besseres Beispiel als der Flur.
Hier ist:
- Powerport mit Gruppe 60 Hauptbeleuchtung
- Powerport mit Gruppe 61 Stehlampe am Schreibtisch
- Rolladen mit Gruppe 61 1. Raffstore gezählt von Norden im Uhrzeigersinn
- Rolladen mit Gruppe 62 2. "
Außerdem habe ich noch gobale Gruppen (wo es sinnvoll ist). Diese beinhalten z.B. das Geschoss (UG/EG/OG 90,91,92) die Himmelsrichtungen (NSOW/96,97,98,99)
Der linke Raffstore im Büro, das befindet sich im EG als Eckraum Nord Ost Ausrichtung. Hat also z.B. folgende 4 Gruppen eingetragen:
Gruppe 0 = 61 Darauf reagiert nur er selbst.
Gruppe 1 = 60 Hauptgruppe Büro (Mit Rolladen_Position_Set=100 an Gruppe 60 fahren alle Raffstores im Büro hoch)
Gruppe 2 = 91 Geschoss EG (Mit Rolladen_Position_Set=100 an Gruppe 91 fahren alle Raffstores im gesamten EG hoch)
Gruppe 3 = 96 Himmelsrichtung (Mit Rolladen_Position_Set=100 an Gruppe 96 fahren alle Raffstores in Himmelsrichtung Nord hoch)
ZitatWaran erkennst du das es eine Lampe und kein Sensor ist?
Am 2. HEX Wert.
Im obigen Beispiel war es eine
11: Power_Group_State_Info
Wenn ein Sensor senden würde, wäre es z.B: eine
47: HELLIGKEITS_INFO oder eine
22: 1WIRE_TEMPERATURE
Ist ein wenig komplex. Hoffe es ist gut genug erklärt...
Lese ich mir morgen in Ruhe durch und dann schauen wir mal wie wir weiter machen.
Grüße
Das gibt ganz schön Kopf auha, aber schauen wir mal was wir zusammen hin bekommen.
Fangen wir erstmal mit dem Master Modul an und arbeiten uns dann langsam vor.
10_openHCAN_hcand.pm
20_openHCAN.pm
Was sagst Du zu der Namensbenennung? Kannst Dich damit anfreunden?
Beim Mastermodul werden wir wohl nicht viel brauchen. Anlegen, aufbau der Socketverbindung, schließen der Socketverbindung. Wenn Du denkst man kann im Master noch sinnvolle Readings setzen dann sag Bescheid.
Grüße
Wir können das open auch weg lassen. Ursprünglich hieß es nur HCAN. Ist weniger "Schreibarbeit".
Sinnvolle Readings für den Master fallen mir grad nicht ein. Die können wir ja auch noch nachlegen.
Da ich nicht wußte, was ich als nächstes am besten mache, habe eben schon mal den HEX String zerlegt, und versuche mich grad daran, mittels der gewonnenen Zahlen die zugehörigen Befehle aus einer hcan xml Datei zu lesen.
So, was lange währt wird endlich gut...
Ich bin mittlerweile überzeugt:
Perl ist die Summe aller Gemeinheiten, die der liebe Gott bei den Frauen nicht unterbringen konnte. ;D
Ich habe das Modul erweitert. Es liest aus der angehangenen xml Datei die HCAN "Befehle" vom Bus und gibt sie im Logfile mit aus.
Ich hoffe, die Zuordung wird damit etwas klarer.
Die Logausgabe sieht nun wie folgt aus:
2017.11.02 19:35:44 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 688d1000040000000501460004930408
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:TASTER_DOWN Gruppe:70 Status:0
!!!Set
!!!Set
!!!Set
!!!Read
2017.11.02 19:35:44 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 68911003040000000511460104930408
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:POWER_GROUP_STATE_INFO Gruppe:70 Status:1
!!!Set
!!!Set
!!!Set
!!!Read
2017.11.02 19:35:45 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:45 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 688d1000040000000502460004930408
2017.11.02 19:35:45 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:TASTER_UP Gruppe:70 Status:0
Das war wohl nix mit der angehängten xml Datei.
Vermutlich war das FHEM Forum nicht sonderlich Begeistert über meine Gedanken zu perl... :'(
Aber jetzt:
Die Ausgaben sehen schon Mal gut aus.
Dann schlage ich vor wir machen die Namensnennung beim automatischen anlegen erstmal mit Gruppe.
Wobei ich da immer noch nicht ganz durch blicke. Ist das nun ein einziges Gerät.
POWER_GROUP_STATE_INFO
Ist ein Lichtschalter hast du gesagt.
TASTER_UP
Ist das der selbe Lichtschalter und sagt mir das das es ein Dimmer ist?
Die Technik ist schon ziemlich komplex. Da ist es bestimmt sehr schwer sich so nebenbei herein zu Denken.
TASTER_DOWN Gruppe:70
wird gesendet, wenn ein Taster bei dem Gruppe 70 eingetragen ist gedrückt wird.
Teilt also den HCAN Powerport-Devices bei denen eine der 4 Gruppen auf 70 konfiguriert ist mit, dass sie Schalten sollen.
POWER_GROUP_STATE_INFO Gruppe:70
wird von den HCAN Powerport-Devices, die die Gruppe 70 eingetragen haben gesendet, sobald der im Device verkjnüpfte Ausgang des Prozessors ein geschaltet ist.
Dh. es ist die Rückmeldung, dass der Prozessor den Schaltbefehl ausgeführt hat. Daher auch das INFO im Namen.
TASTER_UP Gruppe:70
wird erst dann gesendt, wenn der Taster wieder losgelassen wird. Führt aber hier zu keiner Reaktion.
Das könnte z.B. bei einem Dimmer sinnvoll sein, damit der elektronische Regler weiß, dass der Taster losgelassen wurde, und der Dimmvorgang beendet werden muß.
Ich hoffe, es wird so langsam klarer...
Sag mal jetzt wo ich da so drüber nach gedacht habe. Im Grunde ist doch nichts fix. Deine Gruppe 70 zum Beispiel. Du hast ja irgendwo irgendwie Mal festgelegt das ist jetzt ein Lichtschalter Wohnzimmer. Im Grunde kann man auch sagen das ist jetzt ein Temperatursensor Badezimmer, oder?
Ich kann also auf Basis Deines Telegrammes nicht prinzipiell festlegen das ist ein Sensor und das ein Aktor. Und bei Aktor du bist Dimmer du bist Taster, da sich jeder selber aufbauen kann was welches Telegramm bedeutet. Also Gruppe und so.
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
^^ ^^ ^^ ^^
von links nach rechts:
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation. (z.B. Taster_Down/Up, Power_Group_On/Off ...)
Es gibt noch weitere Gruppen, in Gruppe 01 z.B. sind Nachrichten zur Erreichbarkeit und Uptime der Controller-Bords. (Vielleicht für später interessant)
11 = Power_Group_State_Info (Hier könnte auch Power_Group_ON/OFF als Befehl kodiert mit 0a/0b stehen)
46 = Gruppe 70
01 = Status EIN / 00 = Status AUS
Was ist an dem Telegramm von oben fix? Was siehst immer gleich aus?
Daten: 688d1000040000000501460004930408
Daten:TASTER_DOWN Gruppe:70 Status:0
Daten: 68911003040000000511460104930408
Daten:POWER_GROUP_STATE_INFO Gruppe:70 Status:1
Daten: 688d1000040000000502460004930408
Daten:TASTER_UP Gruppe:70 Status:0
Ist das ein und der selbe Schalter aus deinem Beispiel von oben?
Wieso ist bei den drei Beispielen bei zwei eine 688d am Anfang und bei einem eine 8991
Kann man davon ausgehen das immer eine 68 als erstes kommt? Also bei allen auf der Welt oder ist das nur bei Dir. Frage nur wegen RegEx ;D
Kannst du mir noch verraten was Dir aus diesem Telegramm
688d1000040000000501460004930408
Eindeutig sagt das es der Lichtschalter Deckenlampe Kinderzimmer(Beispiel) ist?
05 und 46
Sind ja beides Gruppen
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation.
Habe gerade Mal drüber nachgedacht. Sicherlich beschreibt die 05 alleine nicht das alles.
Meintest du damit das 05 die Beschreibung einleitet? Also alles was nach 05 kommt zum Beispiel
05 01460004930408
In dem Fall würde 05 bedeuten das alles danach die Daten für die devicekommunikation enthält
Also 01460004930408 ist dann die devicekommunikation
01 01460004930408
Hier wäre alles nach 01 Daten für Erreichbarkeit und uptime des Controlerboards. Welches das ist steht dann sicher auch im Folgecode, oder?
Also beschreibt die Stelle 9 zu was die Folgedaten gehören.
Gruppe 70 also die 46 steht nun für den Schalter(Beispiel Flur)? Kann ich also die 70 nehmen und in FHEM eintragen und wenn ich da ein on sende geht auch wirklich der Schalter Flur an?
Grüße
Gedankenblitz Gedankenblitz
Eigentlich geht es ja gar nicht um direkte Devices, also nicht in erster Linie.
Es geht ja um Controlerboards. Eigentlich ist ein Device erstmal ein Controlerboard. Die die Ein und Ausgänge stehen für ein entsprechendes zu schaltenes Device. Es können also auch 2 oder 3 Lampen an ein Board dran sein. Frage ist nun. Woran unterscheiden sich die Boards im Bezug auf das Datagramm? Gibt ja bestimmt eine einmalige BoardId oder so.
Und wie kann ich nun Anhand der Daten vom Board sehen wie viele Devices tatsächlich damit geschalten werden. Das könnte man dann als Channels abbilden. Also das Board ist das Hauptgerät und dann werden noch Channel Devices angelegt. Die Channeldevices bekommen als attribut subType wo dann ausgewählt werden kann THSensor oder Switch oder Dimmer oder Rolladenblabla
Grüße
Guten Morgen!
Ich bin zwar auch schon seit 2 Std. wach, war aber nicht so produktiv wie Du. Hut ab!
Ich hoffe, ich bin nicht der Grund für Deine Bettflucht?!?
Also Du bist nah dran, aber auch weit weg...
Ich glaube Dir geht es grad ähnlich, wie mir mit dem OSI Modell, da hab ich auch Zeit und verschiedenen Erklärungen gebraucht, bis ich das verstanden hatte.
Verabschiede Dich einfach von den Boards. Das ist ein Layer den wir hier nicht benötigen.
Die haben eine Adresse. Diese Adresse ist auch in den Paketen enthalten die wir Empfangen. Die ist aber völlig unrelevant und dient ausschließlich der Wartung der Boards. Also: Firmware updates, Ändern der Konfiguraton.
D.H. Du verbindest dich über die Boardadresse auf das Controllerboard. Sagst: Create Device Taster um einen Taster zu erstellen. Der Taster bekommt vom Controllersystem eine ID zugeweisen sagen wir mal die 23. Dann sagst Du: Edit 23. und kannst Dir mit List die Konfiguration anzeigen lassen.
Wenn Dein phyischer Taster an Port5 des Controllers angeschlossen ist, legst Du das mit "set Port 5 in der Konfiguration des Tasters fest.
Danach kannst Du mit set Gruppe 70 sagen, dass der Taster unter der Gruppe 70 senden soll. Damit ist das angelegte Tasterdevice konfiguriert.
Du kannst auf diesem Controller aber noch x andere Devices anlegen. Z.B. Powerport, Rolläden usw. bis alle der 8 Ein und 20 Ausgänge vergeben sind.
Auf den Boards werden, wie gesagt, Devices angelegt. Im Prinzip wie bei FHEM. Dieses Devices können Taster, Powerports, Rolladen, Temperatursensoren oder auch eine Zeitschaltuhr sein. https://github.com/hcanIngo/openHCAN/wiki/device (https://github.com/hcanIngo/openHCAN/wiki/device)
Die Daten auf dem Bus:
Alles was an für uns relevanten Nutzdaten (Stelle 9-12 im hex) auf dem Bus gesendet wird, findet sich in der oben angehängten XML Datei.
Die Kommunikation ist in Gruppen aufgeteilt. Die Nachrichten-Gruppe 05 ist erstmal am interessantesten, da dort die Schaltbefehle und Info Nachrichten der Devices enthalten sind.
Die Nachrichten-Gruppe Steht an 9. Stelle im hex code.
Anhand des hex Codes läßt sich nicht direkt ermitteln, ob die Mitteilung von einem Aktor oder von einem Sensor kommt.
Das Wichtigste ist:
Die Kommunikations-Gruppen (Stelle 11 im Hex) werden immer im Zusammenhang mit der Nachricht (Stelle 10 im hex) interprätiert.
Nehmen wir mal den o.g. Taster. Dessen Device (im HCAN Controller) auf Kommunikations-Gruppe 70 programmiert ist.
In der Standardeinstellung sendet er beim Drücken: TASTER_DOWN 70. Beim loslassen TASTER_UP 70.
Ein Powerport z.B: ist so programmiert (also intern im C Quellcode), dass er auf alle Events des Typs TASTER_DOWN reagiert.
Wenn der User ihm dann auch noch die Gruppe 70 eingetragen hat weiß er, dass er reagieren muß wenn TASTER_DOWN 70 gesendet wird.
Ich hoffe, es ist etas mehr Licht ins Dunkel gekommen?!?
Verdammt.
Also
Zitat
Der Taster bekommt vom Controllersystem eine ID zugeweisen sagen wir mal die 23. Da
Wo bekomme ich diese ID her aus dem Telegramm??? Das ist das was ich brauche um das Gerät eindeutig zu identifizieren. So das ich in FHEM ein Device angelegt bekomme was im DEF 23 zu stehen hat und wo ich dann sagen kann subType Switch so das mir als set nur on oder off angezeigt wird (und bisschen on-for-timer oder so).
Verstehst was ich meine?
Grüße
Es tut mir leid, aber so funktioniert das System nicht.
Die 23 ist eine Interne Devicenummer auf dem Controller. Damit das Device im EDS (ist so eine Art Dateisystem für EProms) angesprochen werden kann.
Du kannst ein Device an keiner Nummer identifizieren.
Der Devicetyp läßt sich durch die Nachrichten die er Versendet/ Empfängt identifizieren.
Ein Taster sendet TASTER_DOWN mit Gruppe 70 und
ALLE Powerports die Gruppe 70 eingetragen haben reagieren darauf. Es kann einer sein, oder auch hunderte.
Außerdem hat ein Tasterdevice noch ein Featurebit, das bei der Konfiguration eingetragwn wird.
Steht dieses auf 0, sendet er TASTER_DOWN => es reagieren Powerports /sofern die Gruppe stimmt
Steht es auf 2 sendet er ROLLADEN_UP => es reagieren Raffstores /sofern die Gruppe stimmt
Steht es auf 4 sendet er ROLLADEN_DOWN => es reagieren Raffstores /sofern die Gruppe stimmt
Die Featurebits waren aus dem Kopf genannt. Kann sein, dass die Nummern verdreht sind. Bin grad unterwegs und schreibe vom Handy.
Wir müssen als eine Nachricht im Zusammenhang mit einer Gruppe versenden/analysieren.
Also die Stellen 10+11 des Telegramms.
Aber dann können auch mehrere Taster die 70 haben. richtig?
Wenn ja muß ich mir was einfallen lassen. Wir brauchen eine eindeutige ID für jedes logische Device was in FHEM angelegt wird.
Ja das stimmt.
Die Lampe in einem Flur z.B. reagiert auf TASTER_DOWN Gruppe 70.
Dann hast Du einen Schalter am Anfang und einen am Ende des Flurs, und beide senden TASTER_DOWN 70 auf den Bus.
Muß denn die ID gleich dem "Telegramm" sein, das ein Device sendet, bzw. auf das ein Device Reagiert?
Könnten wir denn dafür die Summe aus Befehl und Gruppe nehmen.
Wenn z.B. die Lampe(n) im Flur abgebildet werden sollen, ist die Device ID "TASTER_DOWN 70". Oder die gesendeten Hex Werte: 01 46
Es muß eine Herleitung aus dem Telegramm möglich sein. Also ja.
Zitat
Könnten wir denn dafür die Summe aus Befehl und Gruppe nehmen.
Da könnte man machen.
Zitat von: GU!DO am 03 November 2017, 13:40:02
Ja das stimmt.
Die Lampe in einem Flur z.B. reagiert auf TASTER_DOWN Gruppe 70.
Dann hast Du einen Schalter am Anfang und einen am Ende des Flurs, und beide senden TASTER_DOWN 70 auf den Bus.
Dann brauche ich also quasi für FHEM ja nur ein Abbild eines Tasters der Gruppe 70 sendet. Korrekt?
Gleichzeitig muß dieses FHEM Device aber auf genau diese Lampe welche auf Gruppe 70 reagiert auf die Telegramme für Gruppe 70 reagieren. Damit wir ein ACK bekommen. Also eine Bestättigung das die Lampe auch tatsächlich geschalten hat.
ZitatDann brauche ich also quasi für FHEM ja nur ein Abbild eines Tasters der Gruppe 70 sendet. Korrekt?
yep!
Ich möchte Dich nicht verwirren - aber der Vollständigkeit halber:
Neben dem TASTER_DOWN Events reagieren die Powerports auch auf POWER_GROUP_ON und POWER_GROUP_OFF.
Das ist wahrscheinlich der eindeutigere Befehl.
Ein Taster sollte also je nach Funktion z.B. senden können:
POWER_GROUP_OFF Gruppe 70 oder in hex: 0a 46 und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46bzw. um einen Rolladen zu steuern zusätzlich zum Befehl und der Gruppe noch die Positon:
HES ROLLADEN_POSITION_SET Gruppe 70 Position 100 oder in hex: 14 46 64ZitatGleichzeitig muß dieses FHEM Device aber auf genau diese Lampe welche auf Gruppe 70 reagiert auf die Telegramme für Gruppe 70 reagieren. Damit wir ein ACK bekommen. Also eine Bestättigung das die Lampe auch tatsächlich geschalten hat.
Richtig!
Dieses FHEM Device muß auf Nachrichten die an Gruppe 70 gesendet werden reagieren. Aber immer mit einem Filter auf die Nachricht selber. Es darf, als Lampe, natürlich nicht auf ein "ROLLADEN_POSITION_SET Gruppe 70" reagieren.
Noch was:
Es gibt eine Datei im hcan System, die optional ist, aber für unsere Zwecke ideal verwendt werden kann. Diese spiegelt die jeweilige Installation als xml Datei wieder:
`<haus>`
`<board addr="400">`
`</board>`
`<board addr="401">`
`<reedkontakt gruppe="1" name="hobbyraum" />`
`<reedkontakt gruppe="2" name="werkstatt" />`
`<tempsensor gruppe="4" name="werkstatt" />`
`<tempsensor gruppe="3" name="waschkueche" />`
`<tempsensor gruppe="5" name="vorratsraum" />`
`<powerport typ="lampe" gruppe="10" name="Vorratsraum" />`
`<powerport typ="lampe" gruppe="20" name="Kueche" />`
`<powerport typ="lampe" gruppe="70" name="Flur" />`
`<tempsensor gruppe="1" name="hobbyraum" />`
`<heizung gruppe="1" name="hobbyraum" />`
`<heizung gruppe="2" name="werkstatt" />`
`</board>`
`</haus>Ich wollte eigentlich für jedes HCANDevice ein FHEM Device erstellen und diese Datei als Grundlage nehmen, um dem User nur die jeweils gültigen Attribute anzuzeigen.
Ein user hätte z.B. ein Device mit: "define LampeImHausflur HCAN_Lampe" angelegt.
Er hätte dann in den Attributen zwischen: Lampe Vorratsraum, Kueche und Flur wählen können und hätte die anderen Devices nicht angezeigt bekommen.
Hätte er ein Raffstore_Device angelegt, hätte er nur eingetragene Raffstores zur Auswahl bekommen, hätte aber zusätzlich noch den Öffnungs-Parameter angeben müssen.
Ich habe keine Ahnung wie wir das am besten in einem einzigen logischen FHEM Device abbilden.
Der Öffnungs Parameter ist für ein Raffstore zwingend. Die Lampe kann damit aber nix anfangen.
Ich hatte im Vorfeld schon mal ein Modul zum Senden gebaut. Soll ich das in unser 2 Modul Konzept einbauen und Du korrigierst es, oder was schlägst Du vor. Nicht das wir parallel am gleichen Arbeiten...
Sorry, oben ist ein Vertipper:
Zitat von: GU!DO am 03 November 2017, 14:50:49
POWER_GROUP_OFF Gruppe 70 oder in hex: 0a 46 und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46
es muß natürlich heißen
POWER_GROUP_ON Gruppe 70 oder in hex: 0a 45 und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46
Häng das einfach mal hier mit an. Am We sollte ich dazu kommen da mal was an zu fangen.
Kannst natürlich gerne auch versuchen die Dinge die Du weißt schon in das 2 Modulkonzept ein zu bauen.
Ok. Ich schaue mal wie weit ich heute Nachmittag komme und schicke die Dateien heute Abend auf die Reise...
Alles was wir bis jetzt haben, wandert dann in das physiche Modul - ok?
Na nur die Anbindung mit den Socket. Alles andere ins logische
Kann ich das denn auch irgend wie als Schleife ausführen lassen?
Mit meinem geliebten try / catch?
Oh nein bitte nicht. Was willst du denn davon die Schleife machen
Dann kann ich direkt reagieren, wenn ein keep-alive paket fällig ist, und sende nicht einfach drauf los...
Kannst du doch so auch. Woran erkennst du wenn ein KeepAlive Packet fällig ist?
Wenn er keine Verbindung mehr zum Socket bekommt:
36 try-
37 {
38 my $frame = $socket->recv( $in_data, MAX_RECV_LEN);
39 &keep_connection_alive;
40 if ( $frame )
41 {
42 print unpack("H*", $in_data),"\n";
43 }
44 }
45 catch
46 {
47 &keep_connection_alive;
48 }
Wenn der Socket sich selber abbaut dann wird dieser von alleine wieder aufgebaut. Das hatten wir im Modul so festgelegt. Aber eigentlich ist das ja schon zu spät. Gibt es da kein Datenpacket was sich vorher meldet. Wenn nicht würde ich einfach alle paar Minuten so ein Telegramm schicken.
Ich hatte es so verstanden, dass dieses Ding:
0 sub HCAN_Test_KeepAlive($) {
1
2 my $hash = shift;
3 ---
4 my $data = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
5 # print Dumper('Dumper: '.$data);
6 ---
7 HCAN_Test_Write($hash,$data);
8 ---
9 InternalTimer(gettimeofday()+30, "HCAN_Test_KeepAlive", $hash);
10 }
alle 30 sekunden keep_alive Pakete schickt?!?
Ja das ist korrekt. Aber innerhalb der read Funktion gibt es ja eine Abfrage das wenn Daten der Länge null kommen die Verbindung getrennt wurde und neu aufgebaut wird. Oder getrennt belassen? Weiß gerade nicht. Man kann ja die 30s auf 300 stellen und schauen ob die Verbindung gehalten wird.
Sorry, hab gestern noch die Module umbenannt, und versucht Deinen (unseren) Code zu verstehen. Dann mußte ich wieder erwarten noch zu einem Kunden, und das war es dann auch mit dem Abend...
Es wäre schön, wenn Du mir ein paar Fragen beantworten würdest, je mehr ich verstehe was vorgeht, desto weniger muß ich Dich nerven.
Im Developer Intro steht:
ZitatDie X_Read-Funktion wird aufgerufen, wenn ein dem Gerät zugeordneter Filedeskriptor (serielle Schnittstelle, TCP-Verbindung, ...) Daten zum Lesen bereitgestellt hat. Die Daten müssen nun eingelesen und interpretiert werden.
Das steht bei uns im Quellcode, und ist wohl die Stelle die Du meinst:
1 if( !defined($len) || !$len ) {
2 ----
3 Log3 $name, 3, "HCAN_hcand ($name) - connection closed by remote Host";
4 HCAN_hcand_Close($hash);
5 return;
6 }
7 ----
8 unless( defined $buf) {
9 ----
10 Log3 $name, 3, "HCAN_hcand ($name) - no data received";
11 return;
12 }
Wenn Read doch nur bei zu verarbeitenden Daten aufgerufen wird, wie kann es dann reagieren, wenn keine Daten kommen.
Oder wird Read sporadisch immer wieder aufgerufen?
Außerdem steht im Wiki:
Zitat
Die Write-Funktion wird durch die Funktion IOWrite() aufgerufen, sobald eine logische Gerätedefinition Daten per IO-Gerät an die Hardware übertragen möchte.
Wir haben ja noch kein 2 Modul Konzept, nutzen sie aber trotzdem. Also wird sie generell zum schreiben genutzt, oder war das nur, weil klar war, dass wir auf 2 Module erweitern?
Innerhalb von _Write steht:
0 return Log3 $name, 3, "HCAN_hcand ($name) - WriteFn socket not connected"
1 unless($hash->{CD});
Was ist der Inhalt von CD?
Diese Zeile kommt oft in Quellcodes vor, leider kann ich sie mir nicht erklären:
my $hash = shift;Wird hier das erste Element des hash Wertes entfernt, ohne es irgendwo zu seichern?
Das hier:
Zitat
Das physische Modul öffnet die Datenverbindung zum Gerät (z.B. CUL) und verarbeitet sämtliche Daten. Es kümmert sich um den Erhalt der Verbindung (bsp. durch Keep-Alives) und konfiguriert das Gerät so, dass eine Kommunikation mit allen weiteren Geräten möglich ist (bsp. Frequenz, Modulation, Kanal, etc.).
hatte ich in Verbindung mit den Aussagen zu _Read _Write und _Parse, so gedeutet, dass das Modul autark läuft, und Daten in die jeweilige Richtung weiterleitet wenn welche von intern oder extern ankommen.
Qualsi als Puffer zwischen der Hardware und FHEM damit, falls die Verbindung zur Hardware hängt, FHEM davon nicht betroffen ist.
Wenn das Modul jedoch genau wie ein logisches Modul in FHEM eingebunden ist, warum benötigen wir dann 2 getrennte Module?
Noch was:
Ich habe mir überlegt, dass es vielleicht sinnvoll ist, das Array mit der Zuordnung der HEX-IDs zu den HCAN-Befehlen, und den Hash , der die lokale Installation abbildet im physischen Device zu erstellen.
Zum einen sind die beiden ja von der Hardware bzw. lokalen Installation abhängig und passen damit gut da herein, zum anderen, ist das für den hash der die lokale Installation abbildet, sinnvoll.
Dieser ist ja mehr oder weniger statisch, und muß so nicht bei jedem erstellen logischen Device mit angegeben werden.
Mir ist allerdings nicht klar, wie ich die beiden im physischen Device so anlege, dass ich sie im logischen wieder abrufen kann.
Vielleicht hättest Du dazu ein Beispiel?!?
Danke schonmal...
Zitat von: GU!DO am 04 November 2017, 08:17:09
Sorry, hab gestern noch die Module umbenannt, und versucht Deinen (unseren) Code zu verstehen. Dann mußte ich wieder erwarten noch zu einem Kunden, und das war es dann auch mit dem Abend...
Ich habe meinen Sohn zu Bett gebracht und bin dann mit eingeschlafen ;D
Zitat
Das steht bei uns im Quellcode, und ist wohl die Stelle die Du meinst:
1 if( !defined($len) || !$len ) {
2 ----
3 Log3 $name, 3, "HCAN_hcand ($name) - connection closed by remote Host";
4 HCAN_hcand_Close($hash);
5 return;
6 }
7 ----
8 unless( defined $buf) {
9 ----
10 Log3 $name, 3, "HCAN_hcand ($name) - no data received";
11 return;
12 }
Wenn Read doch nur bei zu verarbeitenden Daten aufgerufen wird, wie kann es dann reagieren, wenn keine Daten kommen.
Oder wird Read sporadisch immer wieder aufgerufen?
Eine Verbindung wird ja nicht einfach so abgerissen. Zu mindest nicht wenn es vernünftig läuft.
Es wird immer etwas gesendet das der Client/Server nun die Verbindung beendet. Dann kommen also immer noch eine Meldung über den Socket aber eben ohne Daten Länge. Zum Beispiel nur ein UDP Header
Denk an das OSI Schichtenmodell
Zitat
Also wird sie generell zum schreiben genutzt, oder war das nur, weil klar war, dass wir auf 2 Module erweitern?
Innerhalb von _Write steht:
0 return Log3 $name, 3, "HCAN_hcand ($name) - WriteFn socket not connected"
1 unless($hash->{CD});
Was ist der Inhalt von CD?
$hash->CD ist unser Kommunikationskanal zum Netzwerkgerät oder was auch immer. Kann ja auch ein USB Stick sein oder eine Datei.
Der Inhalt ist das was wir daruber schreiben oder lesen. Der von Dir zitierte Code schaut nicht nach dem Inhalt sondern ob der Hash Wert generell vorhanden ist.
Zitat
Diese Zeile kommt oft in Quellcodes vor, leider kann ich sie mir nicht erklären:
my $hash = shift;
Wird hier das erste Element des hash Wertes entfernt, ohne es irgendwo zu seichern?
Wieso nicht gesichert. Der erste Wert der letzten Variablen wird als $hash deklariert. $hash selber ist ein Zeiger auf die Systemvariable %hash.
Wichtig ist das was vor dieser Zeile steht, es ist nämlich der Beginn einer neuen sub, demzufolge macht ein shift den ersten Wert der Übergabe in $hash zu schreiben.
Das macht man/ich so wenn ausschließlich $hash an die Sub übergeben wird und sonst nichts. Also
blabla($hash);
sub blabla($) {
Man kann das auch mit mehreren machen
blabla($hash,$wert1,$wert2);
sub blabla($$$) {
my $hash = shift;
my $wert1 = shift;
my $wert2 = shift;
Aber das ist ja schlecht finde ich
Zitat
Das hier:
hatte ich in Verbindung mit den Aussagen zu _Read _Write und _Parse, so gedeutet, dass das Modul autark läuft, und Daten in die jeweilige Richtung weiterleitet wenn welche von intern oder extern ankommen.
Qualsi als Puffer zwischen der Hardware und FHEM damit, falls die Verbindung zur Hardware hängt, FHEM davon nicht betroffen ist.
Wenn das Modul jedoch genau wie ein logisches Modul in FHEM eingebunden ist, warum benötigen wir dann 2 getrennte Module?
Benötigt man eigentlich nicht. Ist aber in meinen Augen sauberer. Man kann so zum Beispiel ein logisches Modul für Aktoren und eines für Sensoren machen und bei verwenden das selbige physische Modul.
Das physische Modul ist ja in der Tat nur die Kommunikationsebene/Abstraktionsschicht zwischen den logischen Modulen und der Hardware. Wenn die Komminikationsbasis die selbe ist kann man zum Beisspiel alle Telegramme im physischen Modul hinterlegen und zuordnen.
01 zum Beipiel on
00 zum Beispiel off
nun reicht es wenn das logische modul als datenwert einfach ein on sendet, die zurodnung erfolgt dann im physischen.
Grüße
Danke für die Erklärungen! :)
my $hash = shift;
Das ist wohl so wie beim "return". Wenn man keinen Wert dazu schreibt, wird einfach der Letzte genommen.
Macht es für einen noob wie mich nicht unbeding leichter... :'(
Bin mal gespannt wie lange es dauert, bis das Ding wiedermal etwas tut, das ich nicht erwartet hätte...
Zitat von: GU!DO am 04 November 2017, 08:52:07
Noch was:
Ich habe mir überlegt, dass es vielleicht sinnvoll ist, das Array mit der Zuordnung der HEX-IDs zu den HCAN-Befehlen, und den Hash , der die lokale Installation abbildet im physischen Device zu erstellen.
Zum einen sind die beiden ja von der Hardware bzw. lokalen Installation abhängig und passen damit gut da herein, zum anderen, ist das für den hash der die lokale Installation abbildet, sinnvoll.
Dieser ist ja mehr oder weniger statisch, und muß so nicht bei jedem erstellen logischen Device mit angegeben werden.
Mir ist allerdings nicht klar, wie ich die beiden im physischen Device so anlege, dass ich sie im logischen wieder abrufen kann.
Vielleicht hättest Du dazu ein Beispiel?!?
Danke schonmal...
Ich würde es so machen. Erstmal als Hash nicht als Array
Im physischen Zuordnung hcan Befehle zu Hex
Im logischen Hex zu hcan Befehl.
Ich glaube da haben wir aneinander vorbei geredet:
Ich habe ja schon ein Array für die Nachrichten auf dem Bus. Die ID entspricht dem HEX-Wert der gesendet wird (konvertiert in Dec) und der Inhalt ist der zugehörige Befehl im Klartext.
In den Hash wollte ich das Installations.xml File abbilden. Dort ist z.B. abgelegt: LampeFlur Gruppe 70
Wenn die Instanz des logischen Devices als Lampe konfiguriert ist:
- hat der user nur ON/OFF zur Auswahl dann
- kann der user im logischen Device zwischen allen im Installations Hash definierten Lampen diejenige auswählen, die er mit der aktuellen Device-Instanz steuern möchte.
- diese Instanz sendet dann ein ON oder OFF an das physische Modul.
Das physiche Modul weiß dann: Lampen-Device, Gruppe und ON und kann die entsprechenden Hex Werte heraussuchen und auf den Bus senden.
Wird der Befehlssatz in HCAN erweitert, oder das Installation.xml File geändert, muß das IMHO nur einmalig das physische Device mit einem reload upgedatet werden.
Hallo Marko,
ich verzweifele so langsam. Hab den ganzen Tag dran geschraubt, aber es will nicht.
Irgend etwas fehlt.
Wenn ich im HCAN Modul den Set Befehl anklicke, erzählt er mir im Log, dass IOWrite ausgeführt wird, aber im HCAN_hcand kommt nix an?!?
Ich habe HCAN im HCAN_hcand als Client eingetragen, und die Forward Deklarationen im Client ebenfalls gemacht.
Es wäre nett, wenn Du nochmal drüberschauen könntest.
Vielen Dank schonmal
Guido
Juhu
Trage mal in das physische Modul ein
sub ..._Initialize($) {
...
$hash->{Clients} = ":HCAN:";
$hash->{MatchList} = { "1:HCAN" => '.*' };
....
Und ins logische
sub ..._Initialize($) {
...
$hash->{Match} = '.*';
...
Das sollte es eigentlich schon gewesen sein.
Grüße
Also den:
$hash->{Clients} = ":HCAN:";
Hatte ich sogar schon! ;D
Aber auch mit den anderen schweigt HCAN_hcand leider...
Noch `ne Idee???
Muss ich mir heute Abend in Ruhe anschauen. Werde das vor allem Mal in mein Testsystem einbauen.
Dass wäre schön, vielleicht sehe ich mir nochmal an, ob der Rückweg nicht so steinig ist?!?
Ab wann würdest Du den frührestens dran gehen können?
Dann präsentieren ich Dir vorher die Körner, die das blinde Huhn vielleicht noch gefunden hat...
Denke nicht vor 21:30 Uhr. Bringe den kurzen ins Bett
OK. Dann schaue ich mal, in wie weit mich meine Kurzen bis dahin machen lassen...
Schau dir andere Module an. Hast du das IODev im logischen Modul gesetzt und Initialisiert?
Oh Mist, hab Deine Frage erst jetzt gesehen.
Hat das Forum eigentlich irgend eine verborgene autoupdate Funktion oder irgend etwas, das bei geöffnetem Fenster ohne F5 zu drücken darauf hinweist, dass ein neuer Betrag eingegangen ist?!?
IODev hab ich nicht gesetzt. Hatte das:
ZitatDas Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.
so verstanden, dass ich das nur bei mehreren "hcand" benötigen würde.
Ich blicke aber nicht durch, auf welchen Wert das gesetzt werden muß. Name des phyischen Devices?!?
Schau dir Mal das Modul GardenaSmart an. Ich glaube da erkennt man alles ganz gut was wie gebraucht wird.
VielenDank für die Blumen :), aber ich glaube, du überschätzt meine perl Fähigkeiten maßlos. :'(
Diese Nummer z.B. kann ich mir z.B. nur rudimentär erklären:
0 foreach my $param ( @a ) {
1 if( $param =~ m/IODev=([^\s]*)/ ) {
2 --------
3 $iodev = $1;
4 splice( @a, $i, 3 );
5 last;
6 }
7 --------
8 $i++;
9 }
Ich würde sagen, er prüft, ob ein Wert im array IODev enthält? Und fügt dann mittels splice irgendwas, irgendwo ein.
Keine Ahnung. Ich habe in keinem meiner Bücher diese Syntax gefunden - Sorry! Eine Stunde für nix.
Letztendlich habe ich beschlossen, dass der Code für mich nicht relevant ist und hab den Rest eingefügt.
Die gute Nachricht, das Modul wird geladen, die schlechte, es wird immer noch nix vom log. zum phys. übertragen.
Ich habe jetzt den ganzen Tag an dem Kram gesessen, und nicht mal Ansatzweise `ne Idee wo es noch hapert.
Mir graut es schon vor der Lieferung der Daten vom phys. an das log. Modul.
Im Gegensatz zu der Nummer von heute, habe ich da nämlich nicht mal `ne Idee wie man es anfangen soll... :-[
Na ja - als Putzmann könnte ich auf jeden Fall gehen. Habe die Module nochmal gründlich gereinigt, Damit Du dich - hoffentlich - wie zuhause fühlst.
Viel Glück und schon mal vielen Dank.
Ich schaue nachher nochmal rein, muß erstmal was anderes sehen. Mir raucht der Schädel...
Ups, die Files - fast vergessen!
Lege gerade die Kinder ins Bett und schaue dann Mal.
Grüße
Bei mir geht es jetzt. Schau mal bitte. Ich habe eigentlich nicht viel geändert
Supi! Vielen Vielen Dank! Das sieht schon sehr viel besser aus. ;D
Werde morgen mal schauen, was Du geändert hast...
Er ruft nun _Write auf, sendet aber noch keine Daten auf den Bus:
2017.11.04 23:02:27 3: HCAN_hcand (HCAN_hcand) - WriteFn called
2017.11.04 23:02:27 3: HCAN_hcand (HCAN_hcand) -
2017.11.04 23:02:27 3: HCAN_hcand (HCAN_hcand) - Write Response: 16
Das wird aber wohl zu schaffen sein. Sehe ich mir morgen nochmal an wenn ich frisch bin.
Könntest Du mir noch kurz auf die Sprüge helfen, bzgl. des Sendens der Daten vom Bus an das logische Device?
Du musst die Dispatcher Funktion aufrufen im physischen Device. Die ruft dann im logischen die ParseFn auf und übergibt die Daten.
Ich muss jetzt erstmal ins Bett. Werde morgen mal in Ruhe Deine Module durch gehen.
Klasse, vielen Dank!
Mir reicht es auch für heute.
Guten Morgen Marko,
nochmals Danke für Deinen nächtlichen Einsatz!
Ich habe eben nochmals mit tcpdump auf das Netzwerk geschaut. So wie ich das auf die Schnelle gesehen habe, sendet das phys. Device Daten, allerdings anscheinend nicht die, die im $data Paket festgelegt sind.
Brauche noch ein wenig, da ich die Kinder mit betreuen muß.
Melde mich!
So, es läuft! ;D
Bis auf eine Kleinigkeit.
Bin mir nicht sicher woran es im Endeffekt gelegen hat, aber nun geht es.
Auf jeden Fall, habe ich in der if Abfrage Miist gebaut, da ich mit = und nicht mit eq verglichen habe.
Außerdem bin ich immer noch am schleudern: Wenn ich in folgendem Code:
1 sub HCAN_hcand_Write($@) {
2 print("!!!Write !!!\n");
3
4 my ($hash,$nachricht,$DeviceID) = @_;
5 my $name = $hash->{NAME};
6
7
8 my $data = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
9
10 # print Dumper('Dumper: '.$nachricht);
11 # print Dumper(my $data);
12
13 if ($nachricht eq 'KeepAlive'){
14 $data = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
15 } elsif ($nachricht eq 'ON'){
16 $data = "\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0a\x46\xb7\xec\x6a\x70\xb7";
17 } elsif ($nachricht eq 'OFF'){
18 $data = "\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0b\x46\xb7\xec\x6a\x70\xb7";
19 }
20
21
22 Log3 $name, 3, "HCAN_hcand ($name) - WriteFn called";
23
24 return Log3 $name, 3, "HCAN_hcand ($name) - WriteFn socket not connected"
25 unless($hash->{CD});
26
27 Log3 $name, 3, "HCAN_hcand ($name) - $data";
28 my $resp = syswrite($hash->{CD}, $data);
29 Log3 $name, 3, "HCAN_hcand ($name) - Write Response: $resp";
30 return undef;
Die Zuweisung in Zeile 8 entferne, und statt dessen die Zuweisungen in der if Abfrage (Zeile 14,16,18) auf "my $data" ändere, bekomme ich eine Fehlermeldung in Zeile 28. Macht doch eigentlich keinen Sinn -oder?!?
Wie dem auch sei, ich kann nun die Funktionen schreiben, die den zu sendenden $data Inhalt in Abhängigkeit der Einstellungen im log. Device generieren.
Vielleicht nochmal zur Kleinigkeit:
Zwischendurch sendet das Device nur nach Verzögerung Daten an hcand. D.h. zwischen Schaltbefehl und Lampe an, vergehen ca. 2 Sekunden...
Solltest Du nun enttäuscht sein, und dich fragen: Was mach ich denn wo das nun läuft mit meiner ganzen vielen Zeit an diesem verregneten Sonntag...
... ich könnte noch Hilfe beim Rückweg also vom phys. zum log. Device gebrauden. ;)
Für Deinen Rückweg fehlt Dir immer noch eine eindeutige ID. Das hätte ich erstmal weg gelassen im logischen Device. Aber irgendwas musst du da noch machen das FHEM auch wirklich nur die passende Lampe oder den Rolladen zuordnen kann.
Der Rückweg, ist mir aber mindesterns genau so wichtig wie der Hinweg. Mir geht es ja vor allem um eine Visualisierung für den Bus.
Es gibt eine Anbindung von openHCAN an openhab. Die ist allerdings so lahm, dass man bei einem Blick auf die Visu nicht sicher sein kann, ob man grad wirklich den akuellen Stand sieht. Das ist für mein Empfinden total unbrauchbar.
Ich verstehe grad nicht, warum eine eindeutige ID fehlt? Wir hatten doch gesagt, dass wir eine Kombination aus Befehl und Gruppe nehmen.
Die zugehörigen Befehle legen den Device Typ fest z.B.POWER_GROUP_STATE_INFO gehört zu einem Powerport, ist also die Rückmeldung für eine Lampe und die Gruppe legt fest, welches Lampendevice genau gemeint ist. Die Gruppe kann dazu in die Attribute des FHEM Device eingetragen werden.
Vom Bus kommt z.B.:
POWER_GROUP_STATE_INFO gruppe:70 status:1 heißt übersetzt: 11 46 mit Status 01 also ON
oder
POWER_GROUP_STATE_INFO gruppe:70 status:0 hier ist die ID: 11 46 mit Status 00 also OFF
Also wäre die id 1146. Korrekt? Und die kannst du auch aus dem Antworttelegramm raus lesen?
Kleines Beispiel:
Du legst dein physisches Device an. Danach drückst Du Deinen Lichtschalter, das dadurch gesendete Telegramm auf dem Bus empfängt das physische Modul und gibt es an den Dispatcher weiter, dieser ruft die ParseFn des logischen Modules auf. Und dort schaust du nach ob es bereits ein Device in FHEM mit der aus dem Telegramm rausgelesenen ID gibt. Wenn nicht wird es angelegt wenn doch wird der Hash ermittelt und die Daten dann weiter zur Verarbeitung gereicht.
Exakt! :D
Hier ist ein Antworttelegramm: 689110030400000005114600a5930408
von Position 9-12 sind die für uns relevanten Daten: 05114600
und an Stelle 10 + 11 stehen die 11 und die 46 (und das ist konstant immer an dieser Stelle!)
Na dann Fang Mal an das in der ParseFn raus zu fischen und in eine Variable zu gießen.
Ich Bau dann heute irgendwann die defineFn entsprechend.
Wozu brauchst du eigentlich den Hash wo als Wert Licht oder so drin steht.
Das ist klasse, Danke!
Du hast doch gesagt, wir sollen alles in ein FHEM-Device packen.
Für die Lampe z.B. benöitge ich ON/OFF und als Befehl POWER_GROUP_ON und POWER_GROUP_OFF
Ein Raffstore hat als Parameter AUF / AB oder auch Position mit einen Attribut und als Befehl z.B. ROLLADEN_POSITION_SET.
dazu kommen dann noch Temperatur, Heizungs div. andere Devices alle mit anderen SET / GET Einstellungen und zu sendenden Befehlen.
Daher habe ich mir gedacht, ich geben beim anlegen des Device einen Paramter mit, der die Funktion der zu erstellenden Instanz angibt.
Das machen wir lieber als Attribut. Das nennen wir subType.
Und bitte nicht vergessen das genau diese Erkennung später automatisch erfolgen sollte. Wäre zu mindest cool wenn das Device gleich den korrekten subType bekommt wenn es automatisch von autocreate angelegt wird.
OK.
Schaue ich mir mit an. Die Set Befehle müssen sich aber in Abhängigkeit vom Typ ändern.
Es muß aber auf jeden Fall mit an das phys. Device gesendet werden, damit es den zu sendenden Befehl ermitteln kann.
Ich habe grad nochmals ein wenig herumgespielt.
Es ist eigentlich Quatsch den Typ Lampe zu nennen.
Powerport passt viel besser. Dann kann der User nachher durch Auswahl des Namens und des Icons das angeschlossene physische Gerät beschreiben.
Ich habe die Umwandlung erstmal im Read auf dem physischen Device gemacht. Dann kann ich mir das auch online direkt im Log ausgeben lassen.
Könnten wir die Funktion nicht auch im phys. Modul belassen, und die "entschlüsselten Daten" an das logische übertragen?
1. Werden die Telegramme im physichen empfangen, dann könnten Sie doch dort auch in eine für das logische Device nutzbare Form umgewandelt werden.
2. Werden die Daten des log. Moduls sowieso im physischen wieder "verschlüsselt" und gesendet.
Ich gehe wie folgt vor:
HEX Werte in Dezimal wandeln.
Der Wert an Stelle 10 wird den jeweiligen logischen Devices Zugeordnet: Powerport, Rolladen...
Der Wert an Stelle 11 kann so genommen werden, der entspricht ja der Gruppenummer.
Der Wert an Stelle 12 ist ein Attribut, kann auch so genommen werden, wird aber nicht für alle Devices benötigt.
Hallo Marko,
ich habe mir das mit dem subType mal angesehen. Kannst Du mir verraten, wie ich eine Liste in ein Attr. bekommen.
Dann könnte man den subType auswählen und könnte damit auch die unter Set angezeigten Befehle anpassen lassen.
sub XiaomiFlowerSens_Initialize($) {
my ($hash) = @_;
$hash->{SetFn} = "XiaomiFlowerSens_Set";
$hash->{GetFn} = "XiaomiFlowerSens_Get";
$hash->{DefFn} = "XiaomiFlowerSens_Define";
$hash->{NotifyFn} = "XiaomiFlowerSens_Notify";
$hash->{UndefFn} = "XiaomiFlowerSens_Undef";
$hash->{AttrFn} = "XiaomiFlowerSens_Attr";
$hash->{AttrList} = "interval ".
"disable:1 ".
"disabledForIntervals ".
"hciDevice:hci0,hci1,hci2 ".
"batteryFirmwareAge:8h,16h,24h,32h,40h,48h ".
"minFertility ".
"maxFertility ".
"minTemp ".
"maxTemp ".
"minMoisture ".
"maxMoisture ".
"minLux ".
"maxLux ".
"sshHost ".
"blockingCallLoglevel:2,3,4,5 ".
$readingFnAttributes;
;D ;D
Danke!
Ich hatte es fast genau so, bin nur nicht drauf gekommen, die einzelnen Einträge durch Punkte zu verbinden. >:(
Hast du zufällig aktuelle Versionen der Module das ich mir das mal anschauen kann?
ja, habe ich.
Ich habe ein subType für die Deviceauswahl und ein Gruppen Attribut eingefügt und wollte nachher die Pakete zum Versenden aus den Daten "automatisch" generieren lassen.
2 Dinge gefallen mir noch nicht:
1. Wenn der subType geändert wird, muß ich eine Reload des Browsers machen, um die geänderten SET Befehle zu sehen
2. Ich wollte dem Gruppen Attr. eigentlich den namen subGruppe geben, damit die Beiden zusammen aufgelistet werden. Dann bekomme ich jedoch kein Eingabe, sondern ein Auswahlfeld.
Vielleicht hast Du dazu ja noch eine Idee?!?
Hallo Marko,
ich verzweifele hier schon wieder und hoffe, dass Du noch eine Idee hast:
Dieses Paket haben wir bisher an den hcand gesendet:
$data = "\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0a\x46\xb7\xec\x6a\x70\xb7"
Da diese Pakete ja bis auf die Stellen 9-12 immer gleich sind, habe ich folgendes vor:
Ich setzte die Stellen 9-12 in 20_HCAN.pm folgender maßen zusammen:
1. Ich wandle den dezimalen Gruppenwert in hex:
my $gruppe_hex = unpack('H*', pack('c*',AttrVal($name,'Gruppe',00)));
2. Ich schreibe die restlichen 3 Stellen je nach gewähltem Device und Schaltzustand (ON/OFF).
Also z.B. "050b" vor, und "bf" hinter die in hex gewandelte GruppenID und wandle das Ergebnis um:
$nachricht = join "", map { '\x' . $_ } unpack("(A2)*",("050b".$gruppe_hex."bf"));
3. Das Ergebnis (mit print $nachricht) ausgegeben, sieht wie folgt aus:
\x05\x0b\x46\xbf
4. Dieses übergebe ich mit IOWrite an 10_HCAN_hcand.pm in die Variable $nachricht.
5. Dort will ich es mit den statischen Bestandteilen zusammensetzten:
$data = "\x00\x8e\x10\x03\x03\x00\x00\x00".$nachricht."\xec\x6a\x70\xb7";
Das Ergenis sieht dann jedoch in etwas wie folgt aus:
����\x05\x0b\x46\xbf�jp�
Die statischen Bestandteile vor und hinter dem von mir erzeugten Teil werden anscheinend als Binär interprätiert?!?
Der generierte Teil aber als String?!?
Fällt Dir dazu was ein???
Hallo Guido
Ich würde erst den String in der WriteFn zusammensetzen und das umwandeln in Hex erst kurz vor dem Absenden machen. Ich bilde mir ein das es anders nicht geht.
Bist Du Dir sicher das wirklich bei allen Installationen von HCAN auf der Welt nur die Stelle 9-12 unterschiedlich ist?
Das mit Deinem zusammensetzen muss ich mir anschauen. Bin leider aktuell zeitlich etwas eingespannt. Aber wie gesagt ich würde das umwandeln ganz zum Schluss kurz vor dem Senden erst machen.
Grüße
Habe mir gerade Deine Files angeschaut. Nicht böse sein, hatte gehofft das Du schon weiter bist. Da fehlt ja doch so einiges. Ich will da jetzt nichts versprechen aber eventuell finde ich morgen etwas Zeit über den Tag.
Wenn du jetzt noch aktuellere Versionen hast häng sie bitte Mal an.
Grüße
So, ich habe es jetzt folgendermaßen umgestellt.
1. Ich generiere im log Device eine Zeichenfolge, die den hex Wert für die Stellen 9-12 darstellt und übergebe diese an das physische Device.
Die Zeichenfolge kommt dann so im phys. Dev. an:
050b46bf
2. Im phys. Dev. Setze ich das Ganze für folgt zusammen:
print $nachricht = "008e100303000000".$nachricht."ec6a70b7";
Ergebnis:
008e100303000000050b46bfec6a70b7
3. ich wandele den String um:
print my $nachricht = join "", map { '\x' . $_ } unpack("(A2)*",($nachricht));
Ergebnis:
\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0b\x46\xbf\xec\x6a\x70\xb7
Das Entspricht exakt dem, was wir in der alten Übergabe hatten:
$data = "\x00\x8e\x10\x03\x03\x00\x00\x00\x05\x0b\x46\xb7\xec\x6a\x70\xb7";
Leider habe ich das gleiche Problem, das wir hatten, als wir den String noch nicht mit Doublequotes eingeschlossen hatten.
TCP-Dump meldet statt der erforderlichen 16 Bit in 64 Bit großes Paket.
Hab schon gefühlte 1000 Varianten probiert, leider bisher ohne Erfolg...
Noch `ne Idee?
Nee Nee, ich bin natürlich nicht böse. Bin ja froh über Deine Hilfe.
Das Problem ist, ich hatte vorher noch nie was mit Perl zu tun und FHEM kenne ich auch erst seit meinem ersten Post in diesem Fred.
Außerdem muß ich ja zwischendrurch auch noch arbeiten und Kinder hüten...
Guten Morgen,
Das verstehe ich, war mein Fehler. Da hatte ich endlich mal Zeit und wollte schnell Dispatcher und ID Zuweisung machen und dann fehlte das drum Rum, da war ich etwas hilflos. Sorry.
Lass uns einfach in Ruhe weiter machen eilt ja nicht.
Aber noch mal zu meiner Frage, in der ganzen Welt auf HCAN Systemen ändert sich nur Stelle 9-12? Am Ende soll das ja nicht nur bei Dir laufen ;D
Grüße
ZitatLass uns einfach in Ruhe weiter machen eilt ja nicht.
Na ja ;)
ZitatAber noch mal zu meiner Frage, in der ganzen Welt auf HCAN Systemen ändert sich nur Stelle 9-12?
Soweit ich es absehen kann, würde ich sagen ja. In "hcan-protocol.xml" sind alle Nachrichten des Busses augeführt, und die werden wie folgt abgebildet:
Stelle 9 - Nachrichtengruppe
Stelle 10 Nachricht
Stelle 11 Device-Gruppe
Stelle 12 Attrribut u.B. 100% bei Rolladen
Hast Du denn eine Idee bzgl. der Hex Konvertiereung aus meinem vorherigen Post???
Bis jetzt noch nicht. Aber ich kann Dir sagen das ich aktuell an den Modulen sitze. Bin gerade dabei die Übergabe vom physischen zum logischen Modul zu machen und das erstellen unser wie ich sie jetzt nenne hcan_id
Was mir auf fällt. Ich weiß nicht wie viel Du bisher so programmiert hast, aber lass mich versuchen ein paar Worte zu sagen vielleicht hilft es Dir.
Eine Funktion sollte immer nur das machen wo für sie da ist und benannt wurde.
Wenn Du also zum Beispiel eine Funktion Read hast und sie dafür da ist Daten von einem Device ein zu lesen dann ist das höhste der Gefühle was die Funktion noch macht zu prüfen ob die Daten tatsächlich angekommen und valide sind. Mehr nicht. Alles andere macht eine weitere Funktion.
Eine Funktion sollte in der Regel nie mehr wie 50 Zeilen Code haben, dient der besseren Übersicht.
Wenn Du innerhalb einer Funktion funktionale Erweiterungen brauchst (beispiel das raus finden eines Devicetypes anhand eines Teilstrings Deiner Daten) dann lagerst Du das in eine weitere Funktion aus und lässt Dir das Ergebnis beim Aufruf gleich zurückgeben und in eine Variable lesen.
my $devType = HCAN_determineDeviceType($hash,$stringpart);
Du musst versuchen etwas mehr Struktur in Deinen Code zu bekommen. Zu mindest am Ende. Oder wenn jemand Dir helfen soll ;D
Im Moment kann ich nicht erkennen wo Du hin willst, daher schreibe ich meinen Code einfach nur an passender Stelle und hoffe das Du dann erkennst was er macht und wie Du ihn mit Deinen Teilen korrekt verbindest.
Desweiteren habe ich ein zwei Beispiel als Kommentar eingetragen wie Du Deinen HEX String besser und Systemschonender zerlegen und bearbeiten kannst.
Also wie gesagt ich sitze aktuell dran.
Grüße
Testen konnte ich es leider nicht.
Aber ich empfehle Dir eh erstmal zu verstehen was der Code macht und den Code ein wenig zu analysieren
Grüße
Hallo Marko,
Klasse, vielen Dank!
Ich habe das Programmieren leider nie wirklich gelernt. Zumindest was prozedurale geschweige denn objektorientierte Programmierung angeht.
Lediglich Assembler / Maschinensparche für Microcontroller hab ich während der Meisterschule beigebracht bekommen.
Alle anderen Sprachen habe ich mir selbst beigebracht. Leider keine soweit, dass ich sie flüssig schreiben könnte. Dafür fehlte leider immer die Zeit.
Ich habe immer mal wieder das ein oder andere Projekt realisiert. Inkl. einer Warenwirtschaft für den Betrieb meiner Eltern.
An die Aufteilung der Funktionen habe ich mich, so wie du sie beschreibst, noch nie gehalten. Ich habe immer eine Funkttion erstellt, wenn ich einen Programmteil mehrfach verwenden mußte. Kann das aber gern ändern. Bin ja für jeden Tip dankbar.
Bei mir brennt grad die Luft. Zudem muß ich gleich noch zu einem Kunden raus.
Werde das ganze auf jeden Fall nachher noch testen, und melde mich.
Vielen vielen Dank erstmal
Guido
Hallo Marko,
nochmals vielen Dank für Deine Arbeit!
Sorry für die späte Rückmeldung. Ich hatte gestern und heute wiedererwarten viel um die Ohren, und bin nur sporadisch dazu gekommen weiter zu machen.
Ich habe noch einige Dinge anpassen müssen, aber nun läuft es.
Ist wirklich toll: Schalter betätigen - Neues Device ist angelegt!
Zwei Dinge, die ich geändert u.a. habe - schau bitte mal, ob das in Deinem Sinne ist:
- Ich lösche den Inhalt des PARTIAL Eintrages auch wenn ParseMessage 0 zurück gibt. (Sonst lief der HASH voll).
- Ich kürze den HEX String direkt bei der Zuweisung im Read auf die entscheidenen 8 Stellen. (Dann werden die IDs übersichtlicher.)
Zur Zeit werden die Devices noch mehrfach angelegt.
Das liegt daran, dass ein Device auf mehrere verschiedene Nachrichten reagiert. (2. Hex der 4) Somit haben wir für ein Device verschiedene IDs.
Ich muß die IDs filtern, und in Gruppen zusammenfassen, damit entschieden werden kann, was zusammen gehört.
Ich könnte dazu die 2. Stelle durch einen gemeinsamen Wert ersetzten. z.B. Alle Powerport Nachrichten haben dezimale Nummern zwischen 10 und 19:
"POWER_GROUP_ON" id="10" Bei Powerport Gruppe 70 = 05 0a 46
"POWER_GROUP_OFF" id="11" Bei Powerport Gruppe 70 = 05 0b 46
Wenn ich nun in der ID die 2. Hex Zahl für Powerport durch 10 ersetzte, hätte der Powerport mit der Gruppe 70 immer 05 0a 46
Die frage ist nur, wie transportiere ich dann den Befehl z.B.POWER_GROUP_ON/OFF. Der ist ja dann nicht mehr in der ID enthalten.
Das beste wird sein, wenn ich ihn direkt in ein Reading schreibe - oder?
Wo soll ich die Auswertung starten? Als Funktion die aus _Parse aufgerufen wird?!?
Vielen Dank nochmals
Guido
Hallo Guido,
Freut mich das Du erste sichtbare Erfolge von Deinen Bemühungen siehst. Das ist immer ja auch wichtig sonst wird es schnell frustrierend.
Ich Antworte Dir morgen ausführlich. Jetzt gönne ich mir ein Eis und schaue noch kurz StarTrek.
Grüße
Na dann, guten Appetit.
Wie kann man denn *kurz* Startrack schauen?!?
OK. War gestern wohl doch schon zu spät für mich.
Als ich die Frage nach *kurzen* Startrack Filmen gestellt habe, war ich gedanklich bei StarWars und da gibts IMHO nicht viel unter 2 Std. länge...
Guten Morgen,
Ich hatte die neuste Serie geschaut. Folge 5 und 6.
Deine Fragen schaue ich mir nachher in Ruhe an.
Grüße
So, ich habe in der Zwischenzeit nochmals über meine Fragen gegrübelt, und werde er erstmal so angehen:
Das logische Device mit Nachrichten zu nerven, die es nicht weiterverarbeiten muß, ist IMHO Unsinn. (Erklärung warum überflüssige Nachrichten siehe meinen Fragen-Fred)
Daher werde ich schon in: HCAN_hcand_ParseMessage folgendes machen:
Ausgangspunkt: "POWER_GROUP_ON" id="10" Bei Powerport Gruppe 70 Entspricht das:
05 0a 46 (00) letzter Wert bei Powerport-Telegramm ungenutzt
Übergeben werde ich mittels Dispatch:
Powerport70-ON
Das sagt dann alles aus.
Im 20_hcan.pm _Parse wird es dann aufgelöst zu:
Zitat
hcan_id = Powerport70 => Das ist dann für einen User bei Device-Neuanlage nicht mehr so cryptisch
Reading state = ON
Folgende Fragen habe ich trotzdem noch:
Wenn ich es richtig sehe, legt FHEM bei return UNDEFINED im _Parse selbstständig ein neues Device an.
Zu diesem Zeitpunkt kenne ich schon die Attribute subType ,Gruppe und außerdem das Reading status.
Wie kann ich diese bei einem neu angelegten Device setzen?
Wenn ich z.B. im Büro alle Raffstores schließen möchte, sende ich eine entsprechende Nachricht die Gruppe 60.
Wenn ich dann eins der 4 Raffstores z.B. wieder öffnen möchte, sende ich je nach dem welches ich öffnen möchte eine Nachricht an die 61,62,63 oder 64.
Das funktioniert, da man bei allen HCAN-Devices bis zu 5 Gruppen eintragen kann.
Wie können wir das am besten abbilden?
Eine Möglichkeit wäre, im HCAN_hcand_ParseMessage eine "Sammelgruppe wie z.B. 60" in die Devicegruppen hier also 61,62,63,64 zu zerlegen, und dementsprechend X Nachrichten zu senden.
evtluelle Probleme:
1. Die Sammelgruppen im HCAN müssen nicht so strukturiert sein wie bei mir.
2. Des weiteren habe ich eine Sammelgruppe für jede Himmelsrichtung. Also Raffstore schließen an Gruppe 98 würde alles auf der Südseite herunterfahren.
Außerdem noch ein für das Geschoss. Also z.B. Alle EG Raffstore schließen.
Und Last but not Least noch eine Gruppe für die Wand im Raum. Also z.B. Esszimmer Straßenseite schließen.
3. D.h. es können aus einer Busnachricht, bei Teilung in Einzelnachrichten schnell mal 20 Einzenachrichten (z.B. alle Raffstores im EG) an den Dispatcher übergeben werden.
Die beste Möglichkeit wäre IMHO, dass der User eine externe Datei anlegt, die seine Gruppenzurodnungen wiederspiegelt. Die könnte dann im 10_HCAN.pm eingelesen werden.
Bleibt dann aber noch die Frage, wie FHEM mit einer Welle von z.B. 20 Nachrichten fertig wird.?!?
Bzw. was passiert, wenn während der Abarbeitung weitere Nachrichten vom Bus kommen?!?
Alternativ könnte man natürlich auch jedem einzelnen Device seine spezifische ID geben und die Gruppen in FHEM bilden. Das hätte dann jedoch den gravierenden Nachteil, dass HCAN nicht mehr autark betrieben werden kann. Wenn also der FHEM Server stirbt, hätte ich ein Problem.
Du kannst doch subType und Gruppe im Define mitgeben :)
Aber wie bekomme ich die Werte dorthin?
FHEM das Device anlegt, habe ich ja noch keinen hash, in dem ich sie ablegen kann?!?
Oder hab ich grad 'n Brett vorm Kopf???
my $hcanid = substr($message,19,22));
my $subType = ???
my $Gruppe = ???
if( defined($hcanid) ) {
if( my $hash = $modules{HCAN}{defptr}{$hcanid} ) {
my $name = $hash->{NAME};
HCAN_WriteReadings($hash,$message);
Log3 $name, 3, "HCAN ($name) - find logical device: $hash->{NAME}";
return $hash->{NAME};
} else {
Log3 $name, 3, "HCAN ($name) - autocreate new device HCANDevice$hcanid with HCAN_ID $hcanid and IODev IODev=$name";
return "UNDEFINED HCANDevice$hcanid HCAN $hcanid $subTyte $Gruppe IODev=$name";
}
}
Du musst natürlich innerhalb der Parse dann entsprechend die Variablen subType und $Gruppe füllen.
Ausserdem musst Du noch die DefineFn anpassen
... war heute mal wieder etwas chaotisch, daher hab ich noch nix geschafft.
Wenn ich innerhalb von _Parse Variablen fülle, sind die doch für die "nächste" Funktion nicht mehr zugänglich?!? Oder soll ich globale Variablen anlegen?
_________________________________________________________________________________________________________________________________________
Sag mir doch bitte noch was Du zu meiner 2. Frage meinst. Ich hoffe nämlich, dass ich morgen bei Zeiten anfange, und zumindest bis annähernd Mittag durchziehen kann:
Wenn ich z.B. im Büro alle Raffstores schließen möchte, sende ich eine entsprechende Nachricht die Gruppe 60.
Wenn ich dann eins der 4 Raffstores z.B. wieder öffnen möchte, sende ich je nach dem welches ich öffnen möchte eine Nachricht an die 61,62,63 oder 64.
Das funktioniert, da man bei allen HCAN-Devices bis zu 5 Gruppen eintragen kann.
Wie können wir das am besten abbilden?
Eine Möglichkeit wäre, im HCAN_hcand_ParseMessage eine "Sammelgruppe wie z.B. 60" in die Devicegruppen hier also 61,62,63,64 zu zerlegen, und dementsprechend X Nachrichten zu senden.
evtluelle Probleme:
1. Die Sammelgruppen im HCAN anderer User können völlig anders strukturiert sein als meine. Es muß also ein für den User konfigurierbares System sein.
2. Des weiteren habe ich eine Sammelgruppe für jede Himmelsrichtung. Also Raffstore schließen an Gruppe 98 würde alles auf der Südseite herunterfahren.
Außerdem noch ein für das Geschoss. Also z.B. Alle EG Raffstore schließen.
Und Last but not Least noch eine Gruppe für die Wand im Raum. Also z.B. Esszimmer Straßenseite schließen.
D.h. es können aus einer Busnachricht, bei Teilung in Einzelnachrichten schnell mal 20 Einzelnachrichten (z.B. alle Raffstores im EG) an den Dispatcher übergeben werden.
Die beste Möglichkeit wäre IMHO, dass der User eine externe Datei anlegt, die seine Gruppenzurodnungen wiederspiegelt. Die könnte dann im 10_HCAN.pm eingelesen werden um aus der Sammelgruppe, die einzelnen Devices anzusprechen.
Bleibt dann aber noch die Frage, wie FHEM mit einer "Welle" von z.B. 20 Nachrichten fertig wird.?!?
Bzw. was passiert, wenn während der Abarbeitung weitere Nachrichten vom Bus kommen?!?
Alternativ könnte man natürlich auch jedem einzelnen Device seine spezifische ID geben und die Gruppen in FHEM bilden. Das hätte dann jedoch den gravierenden Nachteil, dass HCAN nicht mehr autark betrieben werden kann. Wenn also der FHEM Server stirbt, hätte man ein Problem.
Die Variablen sind dann nicht mehr zugänglich, das stimmt. Aber wohl deren Inhalt.
Das was ich mit dem define geschrieben habe ist doch nichts weiter als wenn Du ein define in der Commandline machst.
Was hälst Du davon wenn Du einfach noch ein weiteres logisches Device für Gruppen machst. So kannst Du dann eine Gruppen ID senden
Es geht mir weniger ums senden, sondern viel mehr ums Empfangen.
Bleiben wir im Büro. 4 Raffstores. IDs die in den HCAN-Device gespeichert sind: jeweils 61,62,63,64 alle gemeinsam haben, die 60 eingetragen.
Um richtig zu Visualisieren, müsste ich 4 FHEM-Devices erstellen. Jeweils mit der Gruppen-ID 61,62,63,64.
Jetzt muß ich aber sicherstellen, dass die 4 FHEM-Devices genau so wie die HCAN-Devices ebenfalls auf eine gesendete 60 vom HCAN-Bus reagieren, um den Status immer synchron zu haben.
D.h. ich benötige eine Zuordung der zusammenfassenden Gruppen zu den in ihnen enthaltenen Einzeldevice IDs.
Die frage ist nur, wenn ich Define in einer Schleife z.B. 20x direkt hintereinander aufrufe:
- bekommt FHEM das geregelt und
- was passiert, wenn parallel neue Nachrichten eintreffen. Schreibt FHEM die schon in irgend eine Puffer, oder hat das Betriebssystem einen Buffer für nicht abgeholte Daten im Filehandle?!?
So nun habe ich mal etwas mehr Zeit zum Antworten.
Also die 60 was ja eine Gruppen ID ist und den Zustand und die Befehle für alle Geräte in der Gruppe 60 beinhaltet hat erstmal nichts mit dem define zu tun. Ich würde auf die 60 erst reagieren wenn das entsprechende Gerät was sich in dieser Gruppe 60 befindet auch schon angelegt wurde. Aber das passiert eigentlich automatisch. Ich würde es so machen, hoffe ich habe es korrekt verstanden, Nehmen wir mal an es kommen Daten für die Gruppe 60 rein mit dem Wert dimUp50 also Raffstore auf 50% hochfahren. (ich benenne das jetzt einfach mal so), dann werden die selben Infos ja hoffentlich nicht noch mal pro Raffstore kommen also noch mal einzeln für 61,62,63,64.
Du weißt das die 60 eine Grippen ID ist und nicht ein einzelnes Device beschreibt, also musst Du vorher herausfinden welches Deiner ganzen Devices die schon angelegt sein müssen in der Gruppe 60 sind. Dazu hast Du ja ein Attribut subType was ja schon die 60 als Wort enthält. So hatte ich Dich mal verstanden gehabt. Was muss also gemacht werden.
sub HCAN_Parse($$) {
my ($io_hash,$json) = @_;
my $name = $io_hash->{NAME};
Log3 $name, 3, "HCAN ($name) - ParseFn was called";
Log3 $name, 3, "HCAN ($name) - JSON: $json";
#### Beispieldaten
# 688d1000040000000501460004930408 68 8d 10 00 04 00 00 00 | 05 | 01 46 00 04 93 04 08
# 68911003040000000511460104930408 68 91 10 03 04 00 00 00 05 | 11 | 46 | 01 04 93 04 08
# 688d1000040000000502460004930408 68 8d 10 00 04 00 00 00 05 02 46 00 04 93 04 08
#Paket in array mit dec Zahlen zerlegen
#my $string = 'AA55FF0102040810204080';
#my @dec = map { hex($_) } ($string =~ /(..)/g);
my $hcanid = substr($message,19,22));
hier prüfst du ob es sich um eine nachricht für eine gruppe handelt
if( was weiß ich vorhanden) {
dann verarbeite die daten in einer anderen Sub weiter
}
if( defined($hcanid) ) {
if( my $hash = $modules{HCAN}{defptr}{$hcanid} ) {
my $name = $hash->{NAME};
HCAN_WriteReadings($hash,$message);
Log3 $name, 3, "HCAN ($name) - find logical device: $hash->{NAME}";
return $hash->{NAME};
} else {
Log3 $name, 3, "HCAN ($name) - autocreate new device HCANDevice$hcanid with HCAN_ID $hcanid and IODev IODev=$name";
return "UNDEFINED HCANDevice$hcanid HCAN $hcanid IODev=$name";
}
}
}
In der anderen sub durchläufst du eine schleife wo du den hash aller geräte raussuchst mit subType gruppenid und rufst dann in der Schleife am ende die WriteReadings Funktion auf wo du den passenden Hash übergibst.
Denn um mehr geht es nicht, es nur darum den korrekten Device Hash raus zu finden und die Info über den aktuellen zustand des Geräte in ein Reading zu schreiben.
Verstehst was ich mein?
Hallo Marko,
sorry, aber ich bin wohl zu blöd für die Übergabe der Attribute an ein neu anzulegendes Device.
Vielleicht kannst Du es nochmal für Lernschwache erklären.
Ich habe in 20_HCAN.pm im _Parse die späteren Attribute subType und Gruppe angelegt. Außerdem wird der aktuelle Status in der Variablen state gespeichert.
Wenn dann ein neues Device mit autocreate angelegt wird, finde ich keinen der 3 Werte in dem Device...
Ich verzweifele hier bald. Mach jetzt erst mal `ne Pause.
Vielen Dank
Guido
Hallo,
Hänge Mal bitte Deine Dateien an. Weiß aber noch nicht ob ich es schaffe am WE zu schauen.
Grüße
Moin Moin,
Sorry für den Streß. Hab gestern den Wald vor lauter Bäumen nicht mehr gesehen... Es läuft jetzt.
Mal sehen wo es als nächstes zwickt... ;)
Hallo Guido,
Na wie schaut es aus. Hoffe Du hast nicht Deinen ganzen Samstag für die Module verschwendet.
Grüße
Moin Marko,
danke der Nachfrage, genau so war es.... und heute morgen um 4 ging es weiter...
Nachdem ich beim senden der Daten absolut nicht weiter kam, habe ich hier noch einen weiteren Fred aufgemacht.
Aktueller Stand:
Empfangen geht. ;D
Autodcreate inkl. aller attribute und readings geht ebenfalls. ;D
Senden geht. ;D
Außerdem habe ich ein Script erstellt, die aus den Backups der HCAN Boards alle Gruppen ausliest, und in Arrays packt.
Powerport[60] enthält nun den String der Einzelkomponenten "61_62_63_64_"
Das schöne ist, dass ich das Backup per Script, oder auch aus FHEM, anstoßen kann, so dass im Falle einer Neukonfiguration alle Daten automatisch eingelesen werden.
Den Pfad zu den Backup Dateien, kann man als Attribut in 10_HCAN_hcand.pm eintragen.
Bin zur Zeit dabei das Script in 10_HCAN_hcand.pm zu integrieren.
So langsam wird es... Dank Deiner Hilfe! ;D ;D ;D
Super. Ich freue mich für Dich. Und Du lernst viel über FHEM und es macht riesen Spaß ;D
Das stimmt, aber ohne Dich hätte ich das wohl nicht geschafft. :-[
Vielen, vielen, vielen Dank. ;D
Wenn ich fertig bin, würde ich es Dir gerne zur Kontrolle senden. OK?
Vorabt hätte ich noch 'ne Frage:
Ich übergebe den pfad zu den Backup Dateien als: "/weg/zu/den/dateien/"
my @fileliste = glob($path."backup-board-*.cf");
liest die Datei aus anstandslos aus, wenn ich jedoch mit:
if (-e $path)
vorab prüfen möchte , ob der angegebene Pfad korrekt ist, meint er, dass der Pfad nicht existent ist.
Hast Du eine Idee?
Versuch Mal
'/weg/zu/den/dateien/'
Ich hole mir den Parameter aus einem Attribut. Wie kann ich beeinflussen ob er in Double- oder Singlequotes "steht"?
Ok das hatte ich verpennt. Ich muss das selber testen.
Nimmt man für Pfad nicht -d? -e ist für Dateien. Vielleicht klappt es ja damit. Wenn nicht muss ich das heute Abend selber Mal testen
Ich hatte gelesen, dass "-e" die Existenz von Verzeichnissen und Dateien testet.
"-d" gibt bei einem Verzeichnis angeblich "DIR" zurück. Habe das aber nicht getestet, da ich dachte, wenn -e schon nicht funktioniert...
Ich teste das nachher mal, und melde mich. Dann hast Du damit nicht auch noch Arbeit! ;)
Servus,
habe jetzt, bis auf die Prüfung des Verzeichnisses für die Powerport alles soweit funktionsfähig. Inkl. Auflösung der Gruppen.
Der Dispatch-Storm beim Anlegen mehrer Einzel-IDs die aus einer Sammelgruppe gewonnen wurden, scheint fhem keine Probleme zu bereiten.
Als nächstes kommen die Raffstores dran.
Kurze Frage:
Wie kann man den FileLogs einen eigenen Raum zuweisen. Die spammen mir nämlich meinen HCAN Raum voll.
Schönen Abend noch
Guido
Keine Ahnung. Aber ich würde das anlegen eines filelogs über autocreate eh verhindern
sub xxx_Initialize($) {
my ($hash) = @_;
...
...
$hash->{noAutocreatedFilelog} = 1;
Perfekt. War eh meine liebste Option.
Hallo Marko,
ich wollte mich mal kurz aus der "Versenkung" melden. Die Woche war ziemlich heftig, da mein Kollege Urlaub hat.
Ich hatte noch ein Problem mit den Raffstores. Das habe ich heute endlich lösen können.
Ich hoffe, dass ich in der kommenden Woche noch die Helligkeits- und Temperatursensoren erschlagen kann.
Im Anschluss würde ich Dir gerne meinen Code zur Durchsicht senden.
Viele Grüße & ein schönes (Rest-)Wochenende
Guido