Fragen zur Stromversorgung, RS485 und Programmierung der Nodes

Beta-User · 04 November 2019, 11:25:59

Was die DS18B20 angeht: Welchen Sketch meinst du genau? Ich würde eher darauf tippen, dass der Speicher vom Arduino nicht ausreicht oder die Spannungsversorgung wegknickt. Wie groß wird der, wenn du mit softserial compilest? (Ich habe mind. einen, der die ID's sendet, auch wenn 3 DS18B20 dran sind, siehe code unten).

Was die Relay-Sketche angeht: Das kann man auch anders machen, es sollte kein Problem sein, in der Regel ausgeschaltet zu starten und dann den Status beim Controller anzufragen, ohne je in den EEPROM zu speichern. Z.B. der hier macht das so: https://github.com/rejoe2/MySensors_Small/blob/master/MyS95_RS485/MyS95_RS485.ino

frober · 04 November 2019, 13:31:43

Diesen https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/tree/master/DallasTemperatureSimple

Bei der Größe bin ich nicht sicher, ich meine um die 20k.
Ich teste mit einem Uno über USB am Netbook und Nano als GW direkt und solo am Test-Raspi.
Am Uno nur die MCP und 3 DS18B20. In der Konsole vom Uno sehe ich alle 3 ID's und Temperaturen.
Konsole vom GW habe ich noch nicht kontrolliert > Todo.
Strom müsste eigentlich reichen, wobei mir einfällt, Nano hat nur 4,2V bei 16MHz Takt.
Da muß ich die Spez. nochmal anschauen > Todo2.

Dein Garagen-Sketch werde ich mir auch anschauen, danke.

frober · 04 November 2019, 13:38:46

Laut Datenblatt "0 to 16MHz at 4.5 to 5.5V"

Das könnte schon das Problem sein.

Beta-User · 04 November 2019, 13:52:41

Ja, 20k sollte kein Ding sein, wobei ich grade keine feste Größe im Kopf habe, ab wann das nicht mehr will (ist wohl auch sketchabhängig bzw. davon, wie viel Speicher man z.B. mit Text "verbrät").

Evtl. kann der auch nicht schnell genug "Saft nachladen" (das hatte ich aber eher früher bei den nRF => kleines wait einbauen zwischen den Sendungen). Wenn der Sketch im Rahmen von Presentation was sinnvolles an der Konsole ausgibt, wird jedenfalls versucht, das auch an den Controller zu senden.

frober · 04 November 2019, 20:15:09

Ein wait(40) führte zum Erfolg, bzw. 2x, eventuell kann man das noch verringern.
Mir war nicht klar, dass die ID im Setup und nicht im Presentation an Fhem übergeben wird. Naja, etwas grübeln führte zum Erfolg.

Also die eigentlich zu niedrige Spannung am Nano scheint erstmal nicht zu stören. Ich habe alle meine aktuell freien Nanos überprüft, nur die letzten Zwei bestellten mit einem FTDI sind betroffen. Die Anderen haben alle ca. 4,8V.
Entsprechend die Dioden gemessen, bei den Problemkindern liegt die Durchlassspannung bei ca. 0,7V, beim Rest bis ca. 0,3V. Hat sich meine vorige Aussage bestätigt.

Habe nun die richtigen Dioden bestellt und werde diese tauschen, nicht dass irgendwann die Spannung doch Probleme macht.

Beta-User · 04 November 2019, 22:43:47

Schön, dass du vorankommst!

Zitat von: frober am 04 November 2019, 20:15:09
Mir war nicht klar, dass die ID im Setup und nicht im Presentation an Fhem übergeben wird. Naja, etwas grübeln führte zum Erfolg.

Na ja, es wird an beiden Stellen übergeben

. In Presentation kann es genutzt werden, die Readingnamen daraus zu machen, deswegen steht es da...

frober · 10 November 2019, 18:04:19

Zitat von: Beta-User am 04 November 2019, 22:43:47
Schön, dass du vorankommst!

...und immer wieder ausgebremst wirst

Leider habe ich wieder ein Problem bei dem ich nicht weiter komme.

Ich habe ein Teil deines "Garagen-Sketch" übernommen:
Relays bei Start alle aus und bei presentation > request

Die Message kommen beim Note an mit on/off, werden jedoch nicht ausgeführt.
message.getBool() ist immer 0

Auszug aus dem Code, ich benutzte die Array-Methode, da meine PINs nicht fortlaufend sind.

Code Auswählen

void receive(const MyMessage &message) {
  if (message.type == V_STATUS) {
    if (message.sensor < noRelays) {          // check if message is valid for relays..... previous line  [[[ if (message.sensor <=noRelays){ ]]]
      Relays[message.sensor].relayState = message.getBool();
      digitalWrite(Relays[message.sensor].relayPin, Relays[message.sensor].relayState ? RELAY_ON : RELAY_OFF); // and set relays accordingly
      //saveState( message.sensor, Relays[message.sensor].relayState ); // save sensor state in EEPROM (location == sensor number)
      }
    if (Relays[message.sensor].relayState == RELAY_ON) {
      startTimeDryRun = millis();
    }
    #ifdef MY_DEBUG
      Serial.print("Incoming change for sensor:");
      Serial.print(message.sensor);
      Serial.print(", New status: ");
      Serial.println(message.getBool());
    #endif
 }
}

Log:

Zitat4235 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=11,pt=0,l=10,sg=0,ft=0,st=OK:MultiRelay
4252 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
4260 TSF:MSG:SEND,100-100-0-0,s=0,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4287 TSF:MSG:SEND,100-100-0-0,s=1,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4313 TSF:MSG:SEND,100-100-0-0,s=2,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4339 TSF:MSG:SEND,100-100-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4365 TSF:MSG:SEND,100-100-0-0,s=4,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4391 TSF:MSG:SEND,100-100-0-0,s=0,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
4418 TSF:MSG:SEND,100-100-0-0,s=1,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
4442 TSF:MSG:READ,0-0-100,s=0,c=1,t=2,pt=0,l=2,sg=0:on
Incoming change for sensor:0, New status: 0
4448 TSF:MSG:SEND,100-100-0-0,s=2,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
4472 TSF:MSG:READ,0-0-100,s=1,c=1,t=2,pt=0,l=3,sg=0:off
Incoming change for sensor:1, New status: 0
4478 TSF:MSG:SEND,100-100-0-0,s=3,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
4503 TSF:MSG:READ,0-0-100,s=2,c=1,t=2,pt=0,l=3,sg=0:off
Incoming change for sensor:2, New status: 0
4509 TSF:MSG:SEND,100-100-0-0,s=4,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
4533 TSF:MSG:READ,0-0-100,s=3,c=1,t=2,pt=0,l=2,sg=0:on
Incoming change for sensor:3, New status: 0
4539 MCO:REG:REQ
4544 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
4568 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
4573 MCO:PIM:NODE REG=1
4578 TSF:MSG:READ,0-0-100,s=4,c=1,t=2,pt=0,l=3,sg=0:off
Incoming change for sensor:4, New status: 0
29390 TSF:MSG:READ,0-0-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
29395 TSF:MSG:BC
30124 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=21,pt=1,l=1,sg=0,ft=0,st=OK:0

Falls der komplette Code nötig ist, kein Problem...

Schon mal Danke

Gruß
Bernd

P.S.: Falls noch nicht bekannt, die Altsoftserial läuft mit dem 16bit-Timer, das heißt alle libs die diesen nutzten laufen nicht. Ich möchte den Gisomat mit den Hardwarecounter auslesen und bin gescheitert.

Lösung: Arduino pro micro (32u4) mit 2 HW-Serial bestellt

Beta-User · 10 November 2019, 18:16:54

...das ist ja sehr seltsam. Welche MyS-lib-Version ist das?

frober · 10 November 2019, 18:25:16

MySensLib 2.3.1

Beim senden des Status aus Fhem kommt 0 und 1 und es funktioniert.

Beta-User · 11 November 2019, 08:04:49

Zitat von: frober am 10 November 2019, 18:25:16
Beim senden des Status aus Fhem kommt 0 und 1 und es funktioniert.

Das verstehe ich zwar nicht wirklich (woher hattest du vorher gesendet...), aber lese ich das richtig, dass es jetzt erwartungsgemäß funktioniert?

(Oder gab es erst keinen abfragbaren Status?)

frober · 11 November 2019, 10:21:42

Beim Start der Node mit requst kommt die Fehm Rückmeldung mit on/off und es funktioniert nicht.
Wenn ich im Betrieb über Fhem "set xxx status on/off" absetzte wird die Meldung mit 0/1 gesendet und es funktioniert.

Soweit ich recherchiert und verstanden habe nimmt getBool() nur 0 oder 1 an.
Wenn als an/off gesendet wird, kann es nicht funktionieren. Da fehlt irgendwo die Umsetzung zu 0/1.

Wenn ich richtig liege, ist beim set aus Fhem on/off vordefiniert, bei der request-Anfrage muss das Reading ausgelesen werden. D.h. die Herkunft des Sollzustandes variiert.
Oder wird das durch V_STATUS von der MySensorsLib umgesetzt?

Beta-User · 11 November 2019, 11:03:18

Ah, Mist...

Das kommt tatsächlich von der Modulseite her, der Unterschied war mir bisher nur noch nicht aufgefallen...
Dann wäre es vermutlich das beste, den Code entsprechend aufzubohren. Bist du halbwegs fit in Perl?

"Man" müßte den onRequestMessage-Code ab Zeile 707 um eine Abfrage erweitern, ob das ein Reading mit "setter" samt mapping ist und dann den gemappten Wert versenden (diese Teile sind die paar Zeilen ab Zeile 305). Im Moment komme ich aber voraussichtlich nicht dazu, das in Ruhe auszutüfteln und zu testen.

(Übergangsweise) Alternative: die Message eben auf der Arduino-Seite auch nach Text auswerten (braucht halt leider deutlich mehr Speicher).

Beta-User · 11 November 2019, 11:48:02

"Man" hat sich das doch mal angesehen, 1. Versuch anbei...

Kann aber sein, dass das gar nicht funktioniert, habe nur kurz den Test gemacht, ob die file überhaupt lädt!

Testen wäre nett, aber schau, dass du ein backup von der originalen File zur Hand hast oder wenigstens den svn-Link!

frober · 11 November 2019, 11:53:15

Super, danke.

Teste heute Abend. Fit im Perl bin ich nicht, lerne aber gerne....

Auf Arduino-Seite habe ich auch schon überlegt. Kann ich einfach mit getChar() oder in der Art die Message abfragen, oder ist getBool() als Funktion im MySensors hinterlegt.
D.h. ich wollte das schon testen, weis aber nicht wie ich on/off aus der Message lesen kann.

Beta-User · 11 November 2019, 11:58:15

MMn wäre es besser, wir würden das auf der FHEM-Seite lösen, von daher ist es klasse, wenn du testen kannst.

Es gibt mehrere "get..."-Funktionen, u.a. auch getString() (soweit ich mich entsinne). Aber auf der PC-Seite tut es viel weniger weh, mit Textfunktionen zu arbeiten wie auf dem Microcontroller, außerdem muß man nichts speziell programmieren, wenn der Controller (hier FHEM) das gleich passend liefert.