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
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 (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
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
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 .
ZitatNur 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 :)
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) ... ..
Gib mal bitte noch ein list vom Device dazu.
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
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.
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
Dann muss da bitte ein anderer Entwickler mal schauen. Mit mehr Überblick. Sorry
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)
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
Zitat von: sn0000py am 04 September 2019, 12:28:39
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.
Zitat von: rudolfkoenig am 03 September 2019, 15:05:31
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).
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
Zitat von: sn0000py am 04 September 2019, 13:09:32
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 :'( ...
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
Das kommt nach meinem Verständnis aus https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Device/MySensors/Constants.pm (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 (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.
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
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.
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?
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.
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
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.
Zitat von: sn0000py am 05 September 2019, 14:12:34
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).
Zitataber 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".
ZitatDreistufig 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.
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?
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.
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?
Zitat von: rudolfkoenig am 05 September 2019, 15:26:51
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
Zitat von: sn0000py 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 ....
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.
Zitateine 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.