Neues Modul entwicklen

[Beta-User]

Ja ich habe die Hardware samt Protokoll schon fertig, und möchte die nun auch so verwenden.

Das ist schon angekommen; das war so gemeint: irgendwie mußt du ja die Daten/Integer-Werte, die da reinkommen, in Readings verwandeln und ggf. dann in die andere Richtung set&get-Befehle codieren. Dazu muß eine Umwandlung erfolgen, die das jeweilige Client-Modul versteht. Im Falle von MQTT2_DEVICE ist das eine im Prinzip völlig flexibel zu definierende topic-(tree)-value-Struktur.
Und da ist eben die Frage, ob es Sinn macht, was eigenes zu entwicken oder auf bestehendes zurückzugreifen .

Zum anderen Punkt, dem schönen Coden, kann ich leider wenig beitragen ...

[sn0000py]

kann mir jemand sagen wo ich infos finde was soetwas macht?

Code Auswählen Erweitern

my $type = $msg->{cmd};
      MESSAGE_TYPE: {
        $type == C_PRESENTATION and do {
          onPresentationMsg($hash,$msg);
          last;
        };
        $type == C_SET and do {
          onSetMsg($hash,$msg);
          last;
        };
        $type == C_REQ and do {
          onRequestMsg($hash,$msg);
          last;
        };
        $type == C_INTERNAL and do {
          onInternalMsg($hash,$msg);
          last;
        };
        $type == C_STREAM and do {
          onStreamMsg($hash,$msg);
          last;
        };

das sieht wie eine Art switch/case aus, nur hat ja perl das nicht ---
woher kommt da das MESSAGE_TYPE

[Beta-User]

Das kommt nach meinem Verständnis aus https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Device/MySensors/Constants.pm, und funktioniert nach meinem (zugegebenermaßen sehr begrenzten) Perl-Verständnis wie switch/case.

MySensors ist im Prinzip eine Art große lookup-table. Das ganze ist vermutlich einfacher zu verstehen, wenn man das hier mal überflogen hat: https://www.mysensors.org/download/serial_api_20

EDIT:
bzgl. des switch-case-Themas siehe z.B. hier: https://stackoverflow.com/a/32943806. Drumrum stehen noch ein paar weitere Varianten, wie man das Problem lösen kann. Aus der Constants.pm kommen im Prinzip nur die Variablenwerte, auf die geprüft wird.

[sn0000py]

So also funktioniert schon mal ganz gut alles.

Die Frage was sich mir stellt, wie bildet man das nun "richtig" (ok wird kein richtig geben - aber schöner) ab

also macht man das so das die relais (habe 7 wert je relais) und dann geräte mit 16 relais drinnen als reading ablegt?
sollte man irgendwelche werte von den readings eher in die internals legen?

Code Auswählen Erweitern

Internals:
   CANID      34
   DEF        34
   IODev      CANGateway
   NAME       testCAN
   NR         15
   STATE      alive
   TYPE       CAN_DEVICE
   READINGS:
     2019-09-05 12:53:28   deviceTyp       4
     2019-09-05 12:53:38   i2cError        0
     2019-09-05 12:53:38   powerOn         7317
     2019-09-05 12:15:15   relais_0_Delay0to1 0
     2019-09-05 12:15:15   relais_0_Delay1to0 1
     2019-09-05 12:15:15   relais_0_DelayTick 0
     2019-09-05 12:15:15   relais_0_PowerOn 16777216
     2019-09-05 12:15:15   relais_0_Schaltspiel 269488130
     2019-09-05 12:15:15   relais_0_State  0
     2019-09-05 12:15:15   relais_0_relayState 0
     2019-09-05 12:15:18   relais_1_Delay0to1 0
     2019-09-05 12:15:18   relais_1_Delay1to0 1
     2019-09-05 12:15:18   relais_1_DelayTick 0
     2019-09-05 12:15:17   relais_1_PowerOn 16777216
     2019-09-05 12:15:17   relais_1_Schaltspiel 269488128
     2019-09-05 12:15:18   relais_1_State  0
     2019-09-05 12:15:18   relais_1_relayState 0
     2019-09-05 12:53:28   serial          0e 00 8a 02 00
     2019-09-05 12:53:38   state           alive
     2019-09-05 12:53:28   swVer           5
   readingMappings:
   sets:
     reboot     
     relais_getInfo
     simulateKey
     time       
Attributes:
   IODev      CANGateway

[CoolTux]

Jedes Relai bildet doch ein physikalisches Device ab, oder? Also eine Lampe oder ein Fernsehr oder was auch immer.
Ich würde pro Relai ein Device anlegen lassen.

[sn0000py]

ja stimmt, kann ich das ganze dann drei stufig machen?

CAN_GATEWAY -> CAN_DEVICE -> CAN_RELAIS ?

wo ist sowas abgebildet? das ich mir das anschauen kann wie das realisiert werden kann?

[Beta-User]

Das ist vom Verteilen der Nachrichten her eine Variante von MQTT2.*, oder?

Wenn das matching genauso gemacht wird wie dort (über eine Art Topic-Tree) kannst du das Device recht einfach "teilen", den Rest sollten die Module automatisch machen (Wenn ein Device mit matchendem Topic da ist, bekommt das die Nachricht, sonst (irgend ?) eines, das die Matching-Kriterien für autocreate erfüllt (bei MQTT2_DEVICE: passende CID).

(Für MySensors klappt das angeblich auch ähnlich, wenn dieselbe NodeID verwendet wird.)

Du solltest versuchen, jedes Relay in den "state" eines Devices zu mappen. Dann kann mit SetExtensions togge, on-for-timer usw. genutzt werden. Im MySensors-Code gibt es dazu auch ein spezielles Attribut, das die Ebene eines dortigen Readings auf "state"-Level "hochzieht" (ist etwas laienhaft erklärt, bei Bedarf bitte nachfragen), bei MQTT2_DEVICE kann man das recht einfach über die Readingsbenennung in der readingList lösen.

[sn0000py]

hmmm, das myDevice kenn eich nicht in FHEM
aber beim MQTT ist es ja so, das ich da trotzdem nur eine zwei stufige Ebene habe
MQTT2_CLIENT -> MQTT2_DEVICE

und da muss ich dann eben meherer MQTT2_DEVICEs anlegen dafür

[CoolTux]

Dreistufig geht nicht. Zwei reichen doch. Du legst dann pro Relai ein logisches Device an. Oder Du machst ein logisches Device und mehrere Kanäle.

[Beta-User]

hmmm, das myDevice kenn eich nicht in FHEM

Hmm, da weiß ich jetzt wieder nicht, was myDevice sein soll... (es war nur zu erkennen, dass du 00_MYSENSORS.pm angeschaut hast, um das IO-Modul zu bauen).

aber beim MQTT ist es ja so, das ich da trotzdem nur eine zwei stufige Ebene habe
MQTT2_CLIENT -> MQTT2_DEVICE

und da muss ich dann eben meherer MQTT2_DEVICEs anlegen dafür

Ja.
Bei MQTT2_.* ist alles (im Ergebnis) zweistufig, wobei dort die Besonderheit ist, dass eine eingehende Nachricht auch an mehrere Clients verteilt werden kann, neben MQTT2_DEVICE sogar noch an MQTT_GENERIC_BRIDGE als anderes Client-Modul.
Wenn du das live sehen willst und irgendeinen ESP8266 ungenutzt rumliegen haben solltest: Mach' da mal Tasmota drauf (für mehrkanalige Geräte wie einen 4-er-Sonoff), wähle das attrTemplate für den 4-fach-Split... (oder schau dir den Code dazu im mqtt2.template-file an, das sollte "der Spur nach" verständlich sein) => macht 4 einzelne Devices, jedes mit schaltbarem "state".

[rudolfkoenig]

Dreistufig geht nicht.

Sowas hoere ich ungern
Natuerlich geht das, sogar beliebig-viel stufig, siehe das STACKABLE Modul.
Ob es hier sinnvoll ist, das habe ich damit aber nicht gesagt.

[sn0000py]

ok ich habs jetzt mal umgebaut auf MQTT2 ähnlich glaub damit wirds für mich schon passen,

so defineire ich das Gerät selbst

Code Auswählen Erweitern


Internals:
   CANID      34
   DEF        34 DEVICE
   DeviceTyp  DEVICE
   IODev      CANGateway
   NAME       canDevice1
   NR         15
   STATE      alive
   TYPE       CAN_DEVICE
   READINGS:
     2019-09-05 15:39:18   alive           1
     2019-09-05 15:39:18   deviceTyp       4
     2019-09-05 15:39:08   i2cError        0
     2019-09-05 15:39:08   powerOn         17247
     2019-09-05 15:39:18   serial          0e 00 8a 02 00
     2019-09-05 15:27:47   state           alive
     2019-09-05 15:39:18   swVer           5
   readingMappings:
   sets:
     reboot     
     relais_getInfo
     simulateKey
     time       
Attributes:
   IODev      CANGateway

und dann pro Relay das ich haben will ein

Code Auswählen Erweitern

Internals:
   CANID      34
   DEF        34 RELAY 0
   DeviceIndex 0
   DeviceTyp  RELAY
   IODev      CANGateway
   NAME       canRelay0
   NR         16
   STATE      0
   TYPE       CAN_DEVICE
   READINGS:
     2019-09-05 15:38:44   Delay0to1       0
     2019-09-05 15:38:44   Delay1to0       1
     2019-09-05 15:38:44   PowerOn         16777216
     2019-09-05 15:38:44   Schaltspiel     269488130
     2019-09-05 15:39:28   alive           1
     2019-09-05 15:38:44   relayState      0
     2019-09-05 15:38:44   state           0
   readingMappings:
   sets:
     getInfo   
Attributes:
   IODev      CANGateway

ist das so üblich das man so savhen wie seriennummer und co in die readings packt?

[Beta-User]

Wegen der ganzen Nacharbeiten solltest du nochmal prüfen, ob es nicht sinnvoller ist, das ganze auf MQTT_DEVICE umzustellen.

Dann die Serial (ggf. in einer Fassung ohne Leerzeichen) als CID nutzen, und die letzten Teile des Topic-Pfades so setzen, wie die Readings heißen sollen...

Den Rest sollte MQTT2_DEVICE dann schon mehr oder weniger alleine machen...

Für Dinge, die der User nicht beeinflussen können soll, würde ich (begrenztes Wissen !) eher Internals verwenden.

[sn0000py]

ich glaube das wird mir zu aufwändig das umzubauen das es mit einem MQTT2_DEVICE dann funkt ....

eine Frage zu Readings/Internal

habe ja auch werte die der User nicht ändern kann/soll, aber die sich trotzdem sehr oft ändern (PowerOn, Schaltspiel usw)
macht das den Internal was aus?

wo würde ich zb werte reingeben, die permanent gespeichert werden sollten?

[CoolTux]

Sowas hoere ich ungern
Natuerlich geht das, sogar beliebig-viel stufig, siehe das STACKABLE Modul.
Ob es hier sinnvoll ist, das habe ich damit aber nicht gesagt.

OK habe es mir noch mal durch den Kopf gehen lassen. Hast natürlich Recht. Gehen würde es, mit dem Sinnvoll, naja. Aber es würde gehen.


Grüße