Anbindung an openHCAN

[CoolTux]

Bei mir geht es jetzt. Schau mal bitte. Ich habe eigentlich nicht viel geändert

[GU!DO]

Supi! Vielen Vielen Dank! Das sieht schon sehr viel besser aus. 
Werde morgen mal schauen, was Du geändert hast...

Er ruft nun _Write auf, sendet aber noch keine Daten auf den Bus:

Code Auswählen Erweitern


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?

[CoolTux]

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.

[GU!DO]

Klasse, vielen Dank!

Mir reicht es auch für heute.

[GU!DO]

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!

[GU!DO]

So, es läuft!   
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:

Code Auswählen Erweitern


  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. 

[CoolTux]

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.

[GU!DO]

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

[CoolTux]

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.

[GU!DO]

Exakt! 
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!)

[CoolTux]

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.

[GU!DO]

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.

[CoolTux]

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.

[GU!DO]

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.

[GU!DO]

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.