Autor Thema: Neues Modul entwicklen  (Gelesen 920 mal)

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Neues Modul entwicklen
« am: 03 September 2019, 14:07:21 »
Hallo ich möchte mir gerne ein neues Modul entwicklen

Ich hier einen Arduino Nano mit CAN (MCP2515) der mir die Frames meiner CAN Nodes empfängt und binär an die USB/serielle ausgibt.

Meine Frage ist, wie baut man das am besten schematisch in FHEM auf?

Ein Device das die USB Verbindung aufbaut und dann je Node eine Verbindung?

Wenn der Node ein Rolladenaktor ist, dann ists klar.
Ich habe aber auch einen Node, der 8 230V Eingänge und 8 Relais hat, der Node ist dann programmiert wie in 8 fach Taster (bei Tastendruck wird das Relais getoggelt)
Sollte man sowas dann auch als ein DEVICE abbilden oder werden das mehrere?

Werden diese Device dann in einem pm File abgebildet oder nimmt man für jeden Typ ein eigenes?

danke für input :D

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #1 am: 03 September 2019, 14:20:17 »
Moin,

klingt nach einem interessanten Projekt, erinnert mich aber sehr stark an MySensors im allgemeinen und meine (am Ende erfolgreichen) Experimente mit CAN-Transceivern statt der RS485-Module im speziellen: https://wiki.fhem.de/wiki/MySensors_Starter_Guide#CAN-Transceiver.

Wenn du was eigenes bauen willst (und nicht die Nodes auf das MySensors-Protokoll aufsetzen willst, was vermutlich einfach wäre, da nur der Kummunikationsteil anders zu code wäre), ist es evtl. eine Idee, zumindest die Modul-Struktur zu übernehmen; da sind zwar einige spezielle Dinge drin (das Matching, wenn ich das richtig verstanden habe), aber der Aufsatz als 2-stufiges Modul ist mWn. Standard. Benötigt würde also ein Modul für das "Device das die USB Verbindung aufbaut" (IO-Modul, bei MySensors 00_MYSENSORS.pm), das dann "irgendwie" ableiten muß, wer der eigentliche Empfänger einer Nachricht ist (Client-Modul, MYSENSORS_DEVICE). Theoretisch kannst du unterschiedliche Client-Module bauen, aber vermutlich ist es einfacher, das in eines zu packen.

Mal sehen, was die richtigen Experten dazu sagen...

Gruß, Beta-User
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #2 am: 03 September 2019, 14:23:00 »
Ich würde ein 2 stufiges Modul machen.
Das physikalische baut die Verbindung zum Arduino Nano mit CAN (MCP2515) aufbaut und dann ein oder mehrere logische welche entsprechend die CAN Nodes abbilden. Wie Du das bei einem 8 fach Taster machst ist Dir überlassen. Kannst ja die Node als logisches Device abbilden und die Relais als Channel wie bei Homemmatic.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #3 am: 03 September 2019, 14:29:00 »
Okay danke, werde mir das mal anschauen.
Die Hardware habe ich schon fertig und läuft zum Teil schon, bis vor kurzem dachte ich das ich mit einem keinen Windows Programm (delphi/Pascel) das ganze in ein MQTT schieben werden.

Nur so spare ich mir den Windows Rechner .

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20891
Antw:Neues Modul entwicklen
« Antwort #4 am: 03 September 2019, 15:05:31 »
Zitat
Nur so spare ich mir den Windows Rechner .
Eine "Seriell nach MQTT Konvertierung" duerfte auf dem Linux Rechner auch nicht so schwer sein, selbst in dem Microcontroller ist das machbar.
Alternativ baust Du ein weiteres IO-Modul fuer MQTT2_DEVICE :)
Zustimmung Zustimmung x 1 Liste anzeigen

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #5 am: 04 September 2019, 11:05:30 »
Hallo hier mal ein kurzer ausschnitt aus dem umgebauten Code den ich nicht verstehe

sub Ready($) {
  my $hash = shift;
  Log3 ("TEST",5,"Ready ".(defined($hash->{USBDev}))." ... ".$hash->{USBDev});
  return DevIo_OpenDev($hash, 1, "CANGATEWAY::Init") if($hash->{STATE} eq "disconnected");
    if(defined($hash->{USBDev})) {
    my $po = $hash->{USBDev};
    my ( $BlockingFlags, $InBytes, $OutBytes, $ErrorFlags ) = $po->status;
  Log3 ("TEST",5,"Ready InBytes ".$InBytes);
    return ( $InBytes > 0 );
    }
}
sub Read($) {

  my ($hash) = @_;
  my $name = $hash->{NAME};

  my $buf = DevIo_SimpleRead($hash);
  Log3 ("TTT", 1, "READ ".$hash." ... ".$buf." .. ".(defined($buf)));
  return "" if(!defined($buf));

  my $data = $hash->{PARTIAL};
  Log3 ($name, 4, "CANGATEWAY/RAW: $data/$buf");
  $data .= $buf;

Im Log bekomme ich beim connecten ein

2019.09.04 11:00:03 5: Start
2019.09.04 11:00:03 3: CANGateway: unknown attribute stateFormat. Type 'attr CANGateway ?' for a detailed list.
2019.09.04 11:00:03 3: Opening CANGateway device COM10
2019.09.04 11:00:03 3: Setting CANGateway serial parameters to 115200,8,N,1
2019.09.04 11:00:03 5: Init
2019.09.04 11:00:03 5: Starting notify loop for CANGateway, 1 event(s), first is connection: connected
2019.09.04 11:00:03 5: createNotifyHash
2019.09.04 11:00:03 5: End notify loop for CANGateway
2019.09.04 11:00:03 3: CANGateway device opened

sieht schon mal gut aus, und die COM10 ist auch gesperrt für REalTerm zB

dann werden der Reihe nach die ready Funktionen aufgerufen
2019.09.04 11:00:05 5: Ready 1 ... Win32::SerialPort=HASH(0x43f5738)
2019.09.04 11:00:05 5: Ready InBytes 0
2019.09.04 11:00:05 5: Ready 1 ... Win32::SerialPort=HASH(0x43f5738)
2019.09.04 11:00:05 5: Ready InBytes 0
2019.09.04 11:00:05 5: Ready 1 ... Win32::SerialPort=HASH(0x43f5738)
2019.09.04 11:00:05 5: Ready InBytes 15
2019.09.04 11:00:05 1: READ HASH(0x39c0d28) ...  ..
2019.09.04 11:00:05 5: Ready 1 ... Win32::SerialPort=HASH(0x43f5738)
2019.09.04 11:00:05 5: Ready InBytes 15

Sieht auch gut aus, und die InBytes werden wenn was kommt erhöht
doch das Read das das DevIo_SimpleRead aufruft, bekommt keinen $buf zurück
2019.09.04 11:02:09 1: READ HASH(0x39c0d28) ...  ..


Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #6 am: 04 September 2019, 11:19:05 »
Gib mal bitte noch ein list vom Device dazu.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #7 am: 04 September 2019, 11:23:18 »
Internals:
   CFGFN     
   DEF        COM10@115200
   DeviceName COM10@115200
   NAME       CANGateway
   NOTIFYDEV  global
   NR         55
   NTFY_ORDER 50-CANGateway
   PARTIAL   
   STATE      opened
   TYPE       CANGATEWAY
   ack        0
   inclusion-mode 0
   outstandingAck 0
   READINGS:
     2019-09-04 11:15:12   connection      connected
     2019-09-04 11:15:12   state           opened
Attributes:
   verbose    5

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #8 am: 04 September 2019, 11:46:37 »
Passt soweit. Kenne mich aber nicht mit Windows aus.

$buf scheint in der Tat leer zu sein. Sprich ohne Daten.Entweder kennt jemand anderes einen Grund oder eine Möglichkeit zu debuggen oder Du schreibst extra Logs in DevIo  :)
Leider habe ich es damals versäumt mir DevIo genauer an zu schauen. Ich schreibe mein Netzwerkhändling immer selbst.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #9 am: 04 September 2019, 12:09:43 »
hmmm laos in der DevIo.pm

sub
DevIo_DoSimpleRead($)
{
  my ($hash) = @_;
  my ($buf, $res);

  if($hash->{USBDev}) {
    $buf = $hash->{USBDev}->input();
Log3 "DevIO", 3, "SimpleRead (".$buf.")";


geht er in diese funktion rein, und da ist der buf schon undef

und ich habe mir in der ready funktion die anderen status sachen ausgeben lassen

my ( $BlockingFlags, $InBytes, $OutBytes, $ErrorFlags ) = $po->status;
    Log3 ($hash->{NAME},5,"Ready InBytes ".$BlockingFlags.", ".$InBytes.", ".$OutBytes.", ".$ErrorFlags);
2019.09.04 12:09:01 5: Ready InBytes 0, 873, 0, 0

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #10 am: 04 September 2019, 12:25:52 »
Dann muss da bitte ein anderer Entwickler mal schauen. Mit mehr Überblick. Sorry
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #11 am: 04 September 2019, 12:28:39 »
eine andere Frage hätte ich noch, wie kann ich eigentlich noch.

Wie kann ich so eine variable eigentlihc per log ausgeben also zB sowas
    my ( $BlockingFlags, $InBytes, $OutBytes, $ErrorFlags ) = $po->status;
Log3 ($hash->{NAME},5,pp($po->status));
das $po->status
wenn ich es einfach so ausgebe steht da 4
habe es schon mit Dumper und co versucht.

und kann ich auch heruasfinden was das $po->status ist, also welcher Variablen Typ (hash array oder co)

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #12 am: 04 September 2019, 12:37:59 »
so, nun geht schon mal was ....

da gibts anscheinende ein bekanntest problem mit dem Win32:Serialport unter 64 Bit

https://forum.fhem.de/index.php/topic,98442.msg917824.html#msg917824

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #13 am: 04 September 2019, 12:48:03 »
eine andere Frage hätte ich noch, wie kann ich eigentlich noch.
[...]
und kann ich auch heruasfinden was das $po->status ist, also welcher Variablen Typ (hash array oder co)
Das muss ein Array sein, sonst würde die Zuweisung der Variablen (my ( $BlockingFlags, $InBytes, $OutBytes, $ErrorFlags ) = $po->status;) nicht funktionieren. Ansonsten kann ich mich CoolTux nur anschließen: der Code an sich sieht passend aus.

Generell tust du dir vermutlich leichter, wenn du entweder ein Linux zum Testen verwendest (ist einfach gängiger), oder ein 32bit-Perl@Windows.

Eine "Seriell nach MQTT Konvertierung" duerfte auf dem Linux Rechner auch nicht so schwer sein, selbst in dem Microcontroller ist das machbar.
Alternativ baust Du ein weiteres IO-Modul fuer MQTT2_DEVICE :)
MQTT2_DEVICE als Client-Modul zu nutzen, finde ich übrigens auch eine klasse Idee! Kann sehr leicht konfiguriert werden...

(MYSENSORS_DEVICE ginge vermutlich ähnlich einfach; das hat den Vorteil, dass es gewisse Datentypen "von Haus aus kennt" - da ist alles nummerisch in der Message-Struktur hinterlegt, hat aber den Nachteil, dass man dieselbe Node/Child-Logik verwenden müßte, das ist in MQTT2_DEVICE völlig flexibel).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #14 am: 04 September 2019, 13:09:32 »
Ja ich habe die Hardware samt Protokoll schon fertig, und möchte die nun auch so verwenden.

Mittlerweile bekomme ich schon Daten rein

Wie schreibt man sowas eigentlich schöner?
my $packetID = ord(substr($buf, 4, 1));
$packetID = ($packetID << 8) | ord(substr($buf, 3, 1));
$packetID = ($packetID << 8) | ord(substr($buf, 2, 1));
$packetID = ($packetID << 8) | ord(substr($buf, 1, 1));

Log3 ($name, 4, "Data : ".sprintf("%08x", $packetID));

Im $buf ist das erste Byte die länge und dann kommt ein integer.
rausbekommen tue ich es aber das muss auch schöner/eleganter gehen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #15 am: 04 September 2019, 13:39:42 »
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 :'( ...
« Letzte Änderung: 04 September 2019, 13:54:32 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #16 am: 04 September 2019, 13:59:51 »
kann mir jemand sagen wo ich infos finde was soetwas macht?

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #17 am: 04 September 2019, 14:16:26 »
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.
« Letzte Änderung: 04 September 2019, 14:37:18 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #18 am: 05 September 2019, 12:55:08 »
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?

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

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #19 am: 05 September 2019, 13:27:41 »
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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #20 am: 05 September 2019, 13:36:25 »
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?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #21 am: 05 September 2019, 13:43:13 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #22 am: 05 September 2019, 14:12:34 »
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

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #23 am: 05 September 2019, 14:28:45 »
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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #24 am: 05 September 2019, 14:29:14 »
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).

Zitat
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".
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20891
Antw:Neues Modul entwicklen
« Antwort #25 am: 05 September 2019, 15:26:51 »
Zitat
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.
Informativ Informativ x 1 Liste anzeigen

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #26 am: 05 September 2019, 15:47:55 »
ok ich habs jetzt mal umgebaut auf MQTT2 ähnlich glaub damit wirds für mich schon passen,

so defineire ich das Gerät selbst
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

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?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #27 am: 05 September 2019, 15:55:06 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sn0000py

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Neues Modul entwicklen
« Antwort #28 am: 05 September 2019, 16:19:00 »
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?

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22091
Antw:Neues Modul entwicklen
« Antwort #29 am: 05 September 2019, 16:22:34 »
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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7610
  • eigentlich eher user wie "developer"
Antw:Neues Modul entwicklen
« Antwort #30 am: 05 September 2019, 16:48:20 »
ich glaube das wird mir zu aufwändig das umzubauen das es mit einem MQTT2_DEVICE dann funkt ....
Ich glaube nicht, dass es besonders aufwändig ist, da der autocreate-Mechanismus recht viel übernimmt. Insbesondere: Es geht davon aus, dass am Ende der Reading-Name steht und behandelt Ziffern im Topic-Tree "speziell".

(Mal ohne den Sonderfall JSON):
Es macht also z.B. aus payload, die an "milight/states/0xBE59/rgbw/0" kommt, ein Reading mit dem Namen "rgbw_0" und dem payload als Inhalt. Du kannst auch angeben, dass das z.B. im Reading "state" landen soll. Oder aus
"shellies/DEVNAME/relay/0/power:.*" das Reading "relay_0_power".

Von Ferne betrachtet, ist vermutlich das einzig schwierige, sowas wie einen Basis-Topic zu definieren, um das von allem anderen sauber abgrenzen zu können. Aber das sollte eine Kleinigkeit sein, die Logik dürfte ja vorhanden sein, was wie aufzudröseln ist.

Zitat
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?
Wenn du es speichern willst, muß es entweder in der Definition stehen (also define oder attr), oder in einem Reading (landet in der statefile). Internals werden zur Laufzeit gebildet (ggf. aus was, was vorhanden ist). Werden wie Werte laufend von der Hardware her kommend aktualisiert und ändern sich, sollten es m.E. Readings sein.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal