Fragen zur Stromversorgung, RS485 und Programmierung der Nodes

Begonnen von frober, 01 Oktober 2019, 19:38:12

Vorheriges Thema - Nächstes Thema

frober

Ja, Fehm-Seite ist natürlich besser....Test läuft heute Abend...

Die Arduino-Info sollte nur für mich zum lernen sein, wenn so ein Fall nochmals auftreten kann ich damit besser die Ursache finden.  ;)   
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Erste Tests erledigt, leider ohne Erfolg... :(
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Ohne Erfolg heißt Absturz oder "nur" weiter on/off?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Alles wie gehabt on/off, sonst hätte ich mehr geschrieben . ;)
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Habe gerade im Log gesehen:
ZitatPERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MYSENSORS_DEVICE.pm line 665.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Ich habe mal ein paar Logmeldungen eingefügt und festgestellt, dass die if-Bedingung in Zeile 713 nicht wahr wird.


2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: MYSENSORS_DEVICE MYSENSOR_100: respond to config-request, node parentId = 0
2019.11.11 19:24:58 5: leaving Sketch Name update
2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: gesendet wird value: on
2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: gesendet wird value: off
2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: gesendet wird value: off
2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: gesendet wird value: on
2019.11.11 19:24:58 5: MYSENSOR_100 is not sleeping, sending message!
2019.11.11 19:24:58 4: gesendet wird value: off


Zitatsub onRequestMessage($$) {
    my ($hash,$msg) = @_;
    eval {
      my ($readingname,$val) = rawToMappedReading($hash, $msg->{subType}, $msg->{childId}, $msg->{payload});
      $hash->{nowSleeping} = 0 if $hash->{nowSleeping};
      my $value = ReadingsVal($hash->{NAME},$readingname,$val);
     if (defined ($hash->{setcommands}->{$readingname})) {
        my ($type,$childId,$mappedValue) = mappedReadingToRaw($hash,$readingname->{var},$readingname->{val});
      $value = $mappedValue;
      Log3 ($hash, 4, "if bedingung wahr, value ist: $value");
     }
       sendClientMessage($hash,
        childId => $msg->{childId},
        cmd => C_SET,
        subType => $msg->{subType},
        payload => $value
      );
     Log3 ($hash, 4, "gesendet wird value: $value");
    };
    Log3 ($hash->{NAME}, 4, "MYSENSORS_DEVICE $hash->{NAME}: ignoring C_REQ-message ".GP_Catch($@)) if $@;
}

Leider sind da meine Perl-Kenntnisse zu schwach um das alles zu verstehen. :-[

Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Hmm, scheine eventuell zu kompliziert gedacht zu haben (ist für mich manchmal auch nicht so einfach nachzuvollziehen, was sich jemand anderes in grauer Vorzeit mal so ausgedacht hat...).

Könntest du mal die in https://forum.fhem.de/index.php/topic,105122.msg992246.html#msg992246 angepinnte Version testen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Das sieht schon besser aus :)

Es wird 0 und 1 beim reboot geliefert, die Pins werden aber noch nicht geschaltet.
Schalten aus Fhem funktioniert einwandfrei.

2263 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=11,pt=0,l=10,sg=0,ft=0,st=OK:MultiRelay
2280 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:0.1
2288 TSF:MSG:SEND,100-100-0-0,s=0,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2314 TSF:MSG:SEND,100-100-0-0,s=1,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2340 TSF:MSG:SEND,100-100-0-0,s=2,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2367 TSF:MSG:SEND,100-100-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2393 TSF:MSG:SEND,100-100-0-0,s=4,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2419 TSF:MSG:SEND,100-100-0-0,s=0,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
2445 TSF:MSG:SEND,100-100-0-0,s=1,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
2468 TSF:MSG:READ,0-0-100,s=0,c=1,t=2,pt=0,l=1,sg=0:1
Incoming change for sensor:0, New status: 1
2473 TSF:MSG:SEND,100-100-0-0,s=2,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
2500 TSF:MSG:READ,0-0-100,s=1,c=1,t=2,pt=0,l=1,sg=0:0
Incoming change for sensor:1, New status: 0
2505 TSF:MSG:SEND,100-100-0-0,s=3,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
2530 TSF:MSG:READ,0-0-100,s=2,c=1,t=2,pt=0,l=1,sg=0:0
Incoming change for sensor:2, New status: 0
2536 TSF:MSG:SEND,100-100-0-0,s=4,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
2561 TSF:MSG:READ,0-0-100,s=3,c=1,t=2,pt=0,l=1,sg=0:1
Incoming change for sensor:3, New status: 1
2566 MCO:REG:REQ
2571 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2594 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2600 MCO:PIM:NODE REG=1
2603 MCO:BGN:STP
2605 TSF:MSG:READ,0-0-100,s=4,c=1,t=2,pt=0,l=1,sg=0:0
Incoming change for sensor:4, New status: 0
2704 MCO:BGN:INIT OK,TSP=1


Schalten aus Fhem:
228433 TSF:MSG:READ,0-0-100,s=1,c=1,t=2,pt=0,l=1,sg=0:1
Incoming change for sensor:1, New status: 1


Ich sehe keinen Unterschied, probiere später im Code eine Pause einzufügen.
Muss gerade nochmal weg...
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Das freut mich erst mal...

Die Abfrage der Controller-Daten machst du in setup(), oder? (Aber eigentlich erschließt sich mir nicht, warum die Node auf die identische Message anders reagiert; das ist doch das, was die Node an debug ausgibt, oder?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Was soll ich sagen....

ich habe es aus deinem Code geliehen ::), da war es in presentation...  ???
In setup funktioniert es. :)

Super, vielen Dank.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

 ;D Der Code stammt im Kern vermutlich auch noch aus Zeiten, in denen setup() vor presentation() ausgeführt wurde. Da war uU. @setup() nicht mal der Transceiver initialisiert ;) ...

Na ja, wie dem auch sei, wenn der Fehler bzgl. smartSleep auch gelöst ist, kommt das ins svn (Achtung: bitte Nebenthread beachten, wenn du smartSleep verwendest, (hoffentlich beseitigte) Absturzgefahr!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Nach ein paar weiteren Schwierigkeiten habe ich nun meine Codes für 3 Nodes zusammen gestrickt.[emoji3]

Jetzt brauche ich nochmal einen gedanklichen Anstoß:

Vorab habe ich angefangen mir eine MyUtils-Routine (meine erste) zu schreiben, mit der ich regenabhängig die Beregnung über die Nodes steuern möchte. Dabei wird die Beregnungszeit(Menge) anhand der letzten Regenmenge berechnet.

Wie kann ich nun am besten die Ventile zeitabhängig teilweise nacheinander steuern?

Geht das mittels Perl (analog millis() ) und wenn wie (bin bei Google nicht weiter gekommen)?
Alternativ kann man die "Minuten" an die Nodes senden, dass diese dann alles autark abarbeiten?
Oder muss ich z.B. in einem Dummy die Zeitreadings setzten und dann mittels notify etc. weiter steuern?

Vorab schon mal Danke
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Ich habe Mal weiter recherchiert, mit time müsste das analog millis funktionieren.
Dann muss ich nur den Loop halten, bis alles abgearbeitet ist.
Dazu habe ich next gefunden....aber noch nicht ganz verstanden.

Wenn ich sleep benutze wird fhem blockiert!?
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Hmm, ich würde das vermutlich anders lösen und die Logik auf der Node autark laufen lassen. Vorschlag dazu:
- Mach die 100%-Zeiten für einzelne Kreise konfigurierbar (0=aus), so dass du nur einen Einschaltbefehl senden mußt, um alle nacheinander/miteinander anzustoßen. Dabei kannst du ja auch einen Prozentwert als Einschaltbefehl senden, also "bewässere 30%" oder "140%", und die Node macht dann daraus die effektiven Werte?
Ggf. kannst du dann auch "häppchenweise" vorgehen lassen, um z.B. das Wasser besser versickern zu lassen (also z.B. 10%-schrittweise rolieren).

Ansonsten kannst du
- Die Node melden lassen, wenn ein Kreis fertig ist => notify oder anderer Eventhandler, der dann den nächsten schaltet;
- Wenn du die Timer in FHEM halten willst, wäre FHEM-sleep möglich (Perl-sleep blockiert!). Ich würde dann aber mit myUtils-Code arbeiten, der einen InternalTimer setzt und sich darüber immer wieder selbst aufruft, die aktuelle Stufe ermittelt und dann auf die nächste umstellt, bis er fertig ist (ähnlich einem Dimmer-Code).

Aber wie gesagt, meine Präferenz wäre, die Node autark arbeiten lassen und nur den relativen Zeitwert vorgeben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Danke Beta-User,

autark ist sicher sinnvoll, deswegen habe ich auch MySensors gewählt.
Aktuell habe ich nur einen "Notaus" im Sketch, um den Garten bei Störungen nicht zu fluten.
Fhem sollte mMn auch nicht mehr als nötig "belastet" werden.

Hast du vielleicht ein Bsp. Für deinen Vorschlag? Ich stehe bei MySensors, wie auch bei Perl nach Anfang.

Erste Gedanken:
Die % auf millis in der Node mappen und beim Startbefehl aus Fhem alle %-Werte für die Ventile mitgeben. Die Nodes arbeitet dann nach und nach alles ab. Die % bleiben unabhängig von on/off der Ventile.  OK soweit?

Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...