Hallo zusammen,
ich plane gerade meine Gartenbewässerung.
Benötigt werden GW (Nano) und 3 Nodes (Mini).
Die Verbindung möchte ich über RS485 herstellen.
Ich gehe davon aus, dass es dem GW egal ist, an welcher Stelle (Anfang/Mitte/Ende) es angeschlossen ist (Terminierung entsprechend).
Ansonsten hätte ich beim 3. Node eine Abzweigung von ca. 6m.
Der weiteste Node ist ca. 40m vom Raspi entfernt (8-poliges Klingel-/Telefonkabel).
1. Kann ich die 5V zentral, mit eigenem Netzteil und vom Ort des Raspis aus versorgen, oder ist die Entfernung zu weit?
2. Falls die Entfernung zu groß ist, würde ein Stepup funktionieren?
3. Bekomme ich Potential-Probleme beim RS485?
4. wenn der GW über den Raspi versorgt wird, muss das RS485 getrennt von den separaten Netzteil versorgt werden?
Mehrere Funktionen (Sensor, Aktor, analogread, interrupt usw.) auf einem Node sind keine Probleme, bis auf den begrenzten Speicher?
Wie schalte ich am besten 24V AC, mit Relais?
Danke und Gruß
Bernd
Edit: Betreff wurde angepasst, da mittlerweile viel mehr Infos zusammengekommen sind.
Zitat1. Kann ich die 5V zentral, mit eigenem Netzteil und vom Ort des Raspis aus versorgen, oder ist die Entfernung zu weit?
Die Verluste werden mit geringerer Spannung immer größer.
(Ja ich denke schon das geht)
Zitat2. Falls die Entfernung zu groß ist, würde ein Stepup funktionieren?
Ja, aber das wäre mir zu kompliziert. Ich speise z.B. 12V ein und habe Stepdowns, bzw. bei wenig Verbrauch einfach an einen 1117er verheizen...
Zitat3. Bekomme ich Potential-Probleme beim RS485?
Unwahrscheinlich, wenn du auf Nummer Sicher gehen willst: CAN Chips sind im allgemeinen noch etwas unempfindlicher: https://wiki.fhem.de/wiki/MySensors_Starter_Guide#Tips_und_Tricks_zu_MySensors-RS485
4. wenn der GW über den Raspi versorgt wird, muss das RS485 getrennt von den separaten Netzteil versorgt werden?
Nein. Persönlich mach ich das jedoch so (über Rj45 Buchsen): https://wiki.fhem.de/wiki/Easy-RS485-Bus Allerdings ist diese Doku etwas mager. Mangels Resonanz habe ich da eher nur mein privates Ding gemacht (wobei einzelne Platinen noch herumliegen; zum Thema CAN habe ich erst die letzten Tage wieder Platinen bestellt.)
Ich bin ehrlich gesagt immer mehr Freund von dem GW eher Mittig... Terminierung siehe easyRS484 mit dem Widerstands-Netzwerk wie das so ähnlich auch z.B. Homematic macht finde ich einen ganz guten Kompromiss. Weniger Stromverbrauch, aber dafür auch nicht maximale Länge... Ich hab das im Forum mal ausgerechnet und bei 19.200 Baud kommt man da noch immer auf viel 100 Meter...
Ok, danke für die Info.
Das macht die Verkabelung einfacher.
Mit der höheren Spannung, guter Tipp.
Hast du auch einen Tipp für die Wechselspannung zu schalten?
Relais habe ich noch genug. Mit Transistor, Diode usw. wird der Aufbau jedoch recht komplex.
Mit einem 4-fach-IC o.ä. wäre es einfacher und kompakter. Bisher habe ich nur für DC gefunden.
Moin,
meine Ventile (24V AC) schalte ich mit SS-Relais (z.B. https://de.aliexpress.com/item/32993864470.html?spm=a2g0s.9042311.0.0.52114c4dK6K9Gw (https://de.aliexpress.com/item/32993864470.html?spm=a2g0s.9042311.0.0.52114c4dK6K9Gw))
Funktioniert sehr gut.
Zuvor hatte ich "Klapperrelais", die trotz Dioden und getrennter Spannungsversorgung ständig zu Problemen geführt haben.
Zitat von: frober am 01 Oktober 2019, 19:38:12
4. wenn der GW über den Raspi versorgt wird, muss das RS485 getrennt von den separaten Netzteil versorgt werden?
Bei mir läuft der RS485-Teil auch so, dass alle Nodes - mit Ausnahme des GW - mit 12V DC versorgt werden und alle (wieder bis auf das GW) auf demselben GND-Level liegen; mit 5V zentraler Versorgung hatte ich Schwierigkeiten, obwohl das nur ca. 25m Kabellänge waren, die darüber versorgt werden sollen. Als Stepdown habe ich dazu (nur optisch verglichen!) diese (https://www.ebay.de/itm/10X-Mini-DC-DC-Converter-Step-Down-Module-Adjustable-3V-5V-16V-for-RC-Plane/123890618821?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D1%26asc%3D57926%26meid%3D63d01d4ae60d469aa03066e6b4c8d7f0%26pid%3D100005%26rk%3D5%26rkt%3D12%26sd%3D333336661892%26itm%3D123890618821%26pmt%3D1%26noa%3D0%26pg%3D2047675&_trksid=p2047675.c100005.m1851) im Einsatz (Achtung: bei denen hatte ich eine hohe Fehlerquote...! Die die laufen, scheinen aber (dauerhaft) ok zu sein.). Empfinde die als besser wie die 1117-er.
ZitatMehrere Funktionen (Sensor, Aktor, analogread, interrupt usw.) auf einem Node sind keine Probleme, bis auf den begrenzten Speicher?
Jep, man muß nur beachten, ob eine Node jetzt schlafen darf oder nicht und den Code entsprechen auf "non-blocking loops" umstellen; die meisten Sensorik-Beispiele legen die MCU schlafen.
Ggf. einfach eine potentere MCU einbauen, wenn der Platz knapp ist. Was auch eine gute Idee ist: Hardwareserial verwenden, am besten auf einer MCU, die mehrere serielle Schnittstellen in Hardware bereitstellt (z.B. ein ATMega32U, wenn du Erfahrung damit hast, ggf. auch was STM32-basiertes wie den Maple (die "Bue-Pill" aber bitte eher nicht...).
Super, danke für eure Infos.
Das erspart mir Fehlplanungen, bzw. Nacharbeit.
Erfahrung, na ja. Kleinere Sachen mit der ArduinoIDE habe ich schon umgesetzt.
MySensors ist da schon eine Nummer größer. Ich werde Stück für Stück testen und mich einarbeiten.
Starte am besten mit dem Bewegungsmelder. Dazu brauchst du nur:
-Arduino
-die MySensors Lib
-einen beliebigen Arduino
Mit dem Finger am Eingangspin kannst du den Bewegungsmelder simulieren.
(OK: was generell immer blöd ist: Du brauchst eine Gateway welches in FHEM eingebunden ist und einen funktionierenden Node. Aber wenn das einmal läuft dann kann es massiv weitergehen...)
Na ja, man braucht streng genommen nur einen Arduino (nämlich das GW) ;) .
Ist aber besser, man testet mit zweien. Für RS485 nicht getestet, aber eigentlich theoretisch mit nur zwei Nodes denkbar: über Kreuz die seriellen Schnittstellen verbinden statt die RS485-Module dazwischenzuklemmen (Muß ich bei Gelegenheit auch mal testen ::) ). (Ansonsten: das mit den CAN-Transceivern (MCP2551) funktioniert wirklich und ist kaum teurer ;) ). (Ich habe übrigens immmer noch irgendwo eine Ladung MAX485-Module rumliegen, wenn die wer brauchen sollte...)
@alru
Welche Maße haben die SS-Relais?
4-fach wäre interessant.
@Beta_User
Gibt es bei den CAN-Transceivern (MCP2551) Besonderheiten bei der Terminierung, oder reichen 120 Ohm am Anfang und Ende?
Momentan habe ich vor je Node eine IP54-Aufputzverzeilerdose 90x90mm zu benutzen (weil vorhanden), da ist der Platz begrenzt.
Die Nodes sitzen dann im Brunnen-, Teichpumpenschacht und Zisterne.
Ich kann, falls nötig, auch alles auf Lochrasterplatinen kompakter zusammen löten. Darin habe ich Übung.
P.S.: Hat jemand Erfahrung mit den AQY212EH laut Datenblatt 60V, 0,55A DC/AC sollten für meine Hunter-Ventile reichen. Kurzzeitig bis 1,5A
Ist auch mit CAN-Modulen as usual. Kann auch gemischt werden. Die Berechnung aller 4 Widerstände richtet sich v.a. nach der Leitungslänge
Zitat von: frober am 02 Oktober 2019, 18:04:52
@alru
Welche Maße haben die SS-Relais?
4-fach wäre interessant.
Moin,
das 4er Relais-Bord hat folgende Abmessungen:
Breite: 56mm
Tiefe: 52mm
Höhe: 24mm
Zitat von: Ranseyer am 02 Oktober 2019, 12:53:58
Starte am besten mit dem Bewegungsmelder. Dazu brauchst du nur:
-Arduino
-die MySensors Lib
-einen beliebigen Arduino
So, die RS495-Module sind endlich, nach Monaten angekommen.
Ich habe einen Nano als GW und einen Uno als Motion-Node, je mit Bsp.-Sketch geflasht. Beim Motion habe ich die Node_ID vor "include MySensors.h" definiert. Bei einem RS495 habe ich die beiden Widerstände entfernt. Alles incl. den 3 LED's am GW verkabelt und in Fhem eingebunden. Autocreate ist aktiviert.
Es wurde nur ID 0 angelegt, das müsste nach meinem Verständnis der GW sein. Wieso wird diese angelegt, wenn keine Sensoren am GW sind?
Die Node habe ich seriell überwacht, das senden der Daten schlägt fehl, bzw. es kommt keine Antwort. Die Kommunikation müsste jedoch vorhanden sein, heißt alle LED's flackern (beide RS485 und LED's am GW), Err. ist aus.
Was ich nicht verstanden habe, PIN2 (Interrupt) ist für RS485 deklariert, angeschlossen werden DE+RE jedoch an PIN10.
Hier die ser. Ausgabe vom Node
Zitat8143 TSF:TDI:TSL
18145 TSM:FAIL:RE-INIT
18147 TSM:INIT
18148 TSM:INIT:TSP OK
18150 TSM:FPAR
18168 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20177 !TSM:FPAR:NO REPLY
20179 TSM:FPAR
20198 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22205 !TSM:FPAR:NO REPLY
22207 TSM:FPAR
22225 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24233 !TSM:FPAR:NO REPLY
24236 TSM:FPAR
24254 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26261 !TSM:FPAR:FAIL
26262 TSM:FAIL:CNT=2
26264 TSM:FAIL:DIS
26266 TSF:TDI:TSL
36269 TSM:FAIL:RE-INIT
36271 TSM:INIT
36272 TSM:INIT:TSP OK
36274 TSM:FPAR
36292 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
38300 !TSM:FPAR:NO REPLY
38302 TSM:FPAR
38321 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
40328 !TSM:FPAR:NO REPLY
40330 TSM:FPAR
40348 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
42355 !TSM:FPAR:NO REPLY
42357 TSM:FPAR
42376 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
44383 !TSM:FPAR:FAIL
44384 TSM:FAIL:CNT=3
44386 TSM:FAIL:DIS
44388 TSF:TDI:TSL
54391 TSM:FAIL:RE-INIT
54393 TSM:INIT
54394 TSM:INIT:TSP OK
54396 TSM:FPAR
54415 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
56423 !TSM:FPAR:NO REPLY
Gruß und Danke
Bernd
P.S.: Die RS485-Module habe 20kOhm nach VCC und GND, laut Berechnung bräuchte ich nur 540 Ohm kann das schon das Problem sein?
Nachtrag: Ok, alles neu verkabelt, dabei verstanden, dass die RX + TX LED's vom GW dauerleuchten und bei Übertragung flackern. Bei den RS485 sind die LED' s nur Power. DE + RE sind nun an PIN2.
Funktioniert leider immer noch nicht >:(
Node-ID-Vergabe hat nicht geklappt.
Warum nicht?
Wo kann ich nach Fehler suchen?
Habe gerade festgestellt, dass der Nano nur 4V bringt, kann das auch ein Problem sein?
Ich habe beide RS485 nun wieder über den Uno versorgt.
Man sieht das an "255-255-..." (such mal nach log Parser auf den MySensors-Seiten).
Du hast sicher mehr als eine potentielle Fehlerquelle, aber ohne NodeID wird es definitiv nicht gehen, das ist zwingend der erste zu beseitigende Punkt. Es war auch keine sooo gute Idee, die Widerstände "präventiv" in dem Umfang zu entfernen: je einer der 120-er an jedem Ende des Bus sind schon sinnvoll, stören tut erst die 4. Node ohne Widerstand (jedenfalls nach meinen praktischen Erfahrungen...).
log Parser habe ich mal gelesen, werde ich heute abend danach schauen.
Ich teste auch mal mit dem Logic-Analyser was die Schnittstelle zu melden hat, bzw. Ob etwas ankommt.
Widerstände bin ich nach Anleitung vorgegangen, einer original, der 2. nur die 20k an VCC und GND entfernt. D.h. 120 an jeder Seite vorhanden.
Ok, das mit den Widerständen hatte ich nur "aus dem Augenwinkel" wahrgenommen, dann sollte das passen.
Wie geschrieben: Die NodeID-Vergabe hat nicht geklappt, das mußt du als erstes fixen (steht da im Sketch "unter" dem, was du manuell festgelegt hattest noch "auto"?), bis dahin kannst du dir m.E. die weitere Fehlersuche sparen.
Ansonsten: den "Starter-Guide" im Wiki hast du gelesen? Da steht u.a. auch das mit "Node_0" usw. drin. Kurz: das ist ganz normal, dass die angelegt wird.
Wiki habe ich gelesen.
Die Sketches habe ich die Bsp. ohne Änderung übernommen. Nur im Motion habe ich die ID vor 'include mysensoers.h' verschoben.
Wo muß 'auto' stehen?
Mit dem MySensors-Wiki bin ich noch nicht weit, da ich vieles übersetzen muß. Mein Englisch ist zu mager um alles zu verstehen.
Es darf eben KEIN auto mehr da stehen, und korrekt: das ganze muß vor das "include"...
So, ich habe alles nochmal kontrolliert und auch den Log Parser benutzt.
Bin ratlos.... :(
Arduino IDE 1.8.5
Board 1.6.20
MySensor 2.3.1
Log GW sollte passen:
Zitat0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RSNGA---,REL=255,VER=2.3.1
0;255;3;0;9;5 TSM:INIT
0;255;3;0;9;7 TSF:WUR:MS=0
0;255;3;0;9;9 TSM:INIT:TSP OK
0;255;3;0;9;12 TSM:INIT:GW MODE
0;255;3;0;9;15 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;18 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.1
0;255;3;0;9;23 MCO:BGN:STP
0;255;3;0;9;29 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;32 TSM:READY:NWD REQ
0;255;3;0;9;52 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Log Node, keine ID :o
Zitat16 MCO:BGN:INIT NODE,CP=RSNNA---,REL=255,VER=2.3.1
26 TSM:INIT
27 TSF:WUR:MS=0
28 TSM:INIT:TSP OK
30 TSM:FPAR
49 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2056 !TSM:FPAR:NO REPLY
2058 TSM:FPAR
2075 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4083 !TSM:FPAR:NO REPLY
4085 TSM:FPAR
4103 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6111 !TSM:FPAR:NO REPLY
6113 TSM:FPAR
6130 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8138 !TSM:FPAR:FAIL
8139 TSM:FAIL:CNT=1
8141 TSM:FAIL:DIS
8143 TSF:TDI:TSL
Sketch vom Motion Node:
/*
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2018 Sensnology AB
* Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
*
* DESCRIPTION
* This is an example of sensors using RS485 as transport layer
*
* Motion Sensor example using HC-SR501
* http://www.mysensors.org/build/motion
*
* If your Arduino board has additional serial ports
* you can use to connect the RS485 module.
* Otherwise, the transport uses AltSoftSerial to handle two serial
* links on one Arduino. Use the following pins for RS485 link
*
* Board Transmit Receive PWM Unusable
* ----- -------- ------- ------------
* Teensy 3.0 & 3.1 21 20 22
* Teensy 2.0 9 10 (none)
* Teensy++ 2.0 25 4 26, 27
* Arduino Uno 9 8 10
* Arduino Leonardo 5 13 (none)
* Arduino Mega 46 48 44, 45
* Wiring-S 5 6 4
* Sanguino 13 14 12 *
*
*/
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable RS485 transport layer
#define MY_RS485
// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 2
// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 9600
// Enable this if RS485 is connected to a hardware serial port
//#define MY_RS485_HWSERIAL Serial1
#define CHILD_ID 1 // Id of the sensor child
#include <MySensors.h>
uint32_t SLEEP_TIME = 120000; // Sleep time between reports (in milliseconds)
#define DIGITAL_INPUT_SENSOR 3 // The digital input you attached your motion sensor. (Only 2 and 3 generates interrupt!)
// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);
void setup()
{
pinMode(DIGITAL_INPUT_SENSOR, INPUT); // sets the motion sensor digital pin as input
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Motion Sensor", "1.0");
// Register all sensors to gw (they will be created as child devices)
present(CHILD_ID, S_MOTION);
}
void loop()
{
// Read digital motion value
bool tripped = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH;
Serial.println(tripped);
send(msg.set(tripped?"1":"0")); // Send tripped value to gw
// Sleep until interrupt comes in on motion sensor. Send update every two minute.
sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME);
}Ich sehe keine Fehler habe aber auch noch keine Erfahrung mit MySensors :(
Gruß und Danke Bernd
Die Child-ID ist nicht gemeint, sondern...
Zitat#define MY_NODE_ID 120
Da ich Konfigurationen brauche die sofort funktionieren liegen diese in meinem Github.
Ist zwar kein Hexenwerk, aber wird trotzdem helfen, einfach mal 1:1 diese beiden Sketche nehmen falls dein nächster Anlauf nicht klappt:
https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/Sketch/Motion_RS485
https://github.com/ranseyer/MySensors-HW/tree/master/Gateway-RFM-RS485/Sketch/MyS-Serial-RS485/MyS-Serial-GW-RS485
Jetzt wo ich es lese, Kopf schlag....danke.
Werde auch deine Bsp. testen/nutzen.
Sie reden miteinander....in die Luft spring. ;D
Wenn man sich auf fertige Bsp. verlässt... :(
Etwas positives...wieder etwas gelernt ;)
Zitat von: Beta-User am 02 Oktober 2019, 12:01:38
Als Stepdown habe ich dazu (nur optisch verglichen!) diese (https://www.ebay.de/itm/10X-Mini-DC-DC-Converter-Step-Down-Module-Adjustable-3V-5V-16V-for-RC-Plane/123890618821?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D1%26asc%3D57926%26meid%3D63d01d4ae60d469aa03066e6b4c8d7f0%26pid%%203D100005%26rk%3D5%26rkt%3D12%26sd%3D333336661892%26itm%3D123890618821%26pmt%3D1%26noa%3D0%26pg%3D2047675&_trksid=p2047675.c100005.m1851) im Einsatz (Achtung: bei denen hatte ich eine hohe Fehlerquote...! Die die laufen, scheinen aber (dauerhaft) ok zu sein.). Empfinde die als besser wie die 1117-er.
Was ist bei dir der Fehler? Ich habe sie mir auch besorgt und gerade festgestellt, dass der Poti zu nah an der Drosselspule sitzt und sich deswegen nicht komplett drehen lässt. Deswegen komme ich nicht weiter runter als auf 7-8 Volt.
Muss wohl heiß nacharbeiten. >:(
Zitat(Ansonsten: das mit den CAN-Transceivern (MCP2551) funktioniert wirklich und ist kaum teurer ;) ).
Welchen Widerstand hast du von PIN8 RS auf Grund?
Wenn ich das Datenblatt richtig verstanden habe, ist in unserem Fall der Wert egal, Hauptsache bei allen am Bus gleich!?
ZitatP.S.: Hat jemand Erfahrung mit den AQY212EH laut Datenblatt 60V, 0,55A DC/AC sollten für meine Hunter-Ventile reichen. Kurzzeitig bis 1,5A
Da ich die Teile schon länger habe, habe ich sie mal getestet. Sind PhotoMos, also letztendlich auch SS-Relays. 560 Ohm vor die LED, ca. 6,5mA (Schaltschwelle 5mA) und die Hunter schalten problemlos. Keine Erwärmung spürbar.
ZitatHabe gerade festgestellt, dass der Nano nur 4V bringt, kann das auch ein Problem sein?
Warum der Nano nur (Messwert) 4,2V bringt ist nun auch klar. Die Originale haben eine Shottky-Diode (Spannungsabfall 0,3-0,4V) um den USB-Port zu schützen. Bei den Clones scheint es eine normale Diode (0,7-0,8V) zu sein.
Fehler auch hier: Spannung läßt sich nicht (auf den gweünschten Wert) einstellen, allerdings war das bei den betroffenen Modulen kein mechanisches Problem, sondern der Poti war schlicht wirkungslos...
Was die Widerstandsgeschichte angeht: Ich hatte erst die MAX485 im Einsatz und habe die (auf den "bekannten" Modulen") durch 487-er Varianten ersetzt gehabt und dabei die überflüssigen Widerstände alle runtergeworfen. Beim Wechsel zu den CAN-Transceivern hatte ich dann erst die TJA1050 im Einsatz. Um die einzubauen, hatte ich dann die fertigen TJA1050-Module mit Lochrasterplatinen auf die vorhandenen Sochel für die MAX-Module adaptiert. Nachdem das mit den hohen Baudraten bei mir zwar geklappt hat (ich verwende hardwareserial), ich aber dann auch eine Lösung haben/testen wollte, die auch mit den default-Baudraten funktioniert, habe ich dann eine Ladung MCP2551 bestellt, und zwar sowohl fertige Module (die sind lila) wie auch IC's. Die IC's habe ich dann auf die (adaptierten...) TJA-Module gelötet.
Was du also auf https://wiki.fhem.de/wiki/Datei:MCP2551_Pro_Micro_GW_Breadboard.PNG siehst, ist ein GW auf ProMicro-Basis (zwei hardare-Serial-Schnittstellen) und auf MCP2551-IC umgelötetem TJA-Modul... Leider kann ich mich grade nicht mehr entsinnen, ob ich von denen irgendwelche Widerstände runter habe, aber im Prinzip bleibt die schlichte Aussage: Busauslegung sollte so sein wie bei RS485 sonst auch üblich.
Die meisten meiner Nodes und auch das GW laufen mit den "TJA-Modulen", die lilanen habe ich nur an einer Node im produktiven Einsatz, sonst zum testen für neue Nodes (die würde ich dann auch gleich entsprechend löten, bei den bestehenden gilt "never touch...").
Bezgl. Widerstand bezog sich nicht auf die Terminierung, sondern lt. Datenblatt
1.7.8 SLOPE RESISTOR INPUT (RS) The RS pin is used to select High-Speed, Slope-Control or Standby modes via an external biasing resistor.
Die meisten verwenden 4,7k, habe aber auch Schaltungen ohne gesehen.
Habe weiter geforscht, die TJA1050 sind lt. Datenblatt am PIN8 standardmäßig auf Masse gezogen.
Ich werde es bei den MCP genauso handhaben (Highspeed).
So, ich habe einige Sensoren testweise zum laufen gebracht.
Aktuell benutze ich den MCP2551 als Transreciever mit 19200 Baud auf Softseriell.
@Beta-User: Ich habe deinen DS19B20_simple-Sketch mit 3 Sensoren getestet. Die ID's kommen in Fhem nicht richtig an, d.h. nur die Letzte und nur sporadisch. In der Konsole sehe ich alle. Liegt das am MCP (kleinerer Puffer o.ä.), oder ist die Baudrate zu gering?
Was mir auch unklar ist, alle Relay-Sketche, die ich bisher angeschaut habe, schreiben den Zustand ins EEPROM. Ist das notwendig?
Bei einer Bewässerung sollten die Relays bei Störung (reboot) doch nicht wieder unkontrolliert einschalten.
D.h. bei Setup werden alle PIN's auf LOW gesetzt und beim Betrieb mit einer Notauszeit überwacht.
Gruß und danke
Bernd
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
Diesen https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/tree/master/DallasTemperatureSimple
(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.
Laut Datenblatt "0 to 16MHz at 4.5 to 5.5V"
Das könnte schon das Problem sein. :-(
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.
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. ;D
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. :o
Habe nun die richtigen Dioden bestellt und werde diese tauschen, nicht dass irgendwann die Spannung doch Probleme macht. ::)
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. ;D
Na ja, es wird an beiden Stellen übergeben ;) . In Presentation kann es genutzt werden, die Readingnamen daraus zu machen, deswegen steht es da...
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.
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
...das ist ja sehr seltsam. Welche MyS-lib-Version ist das?
MySensLib 2.3.1
Beim senden des Status aus Fhem kommt 0 und 1 und es funktioniert.
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?)
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?
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).
"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!
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.
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.
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. ;)
Erste Tests erledigt, leider ohne Erfolg... :(
Ohne Erfolg heißt Absturz oder "nur" weiter on/off?
Alles wie gehabt on/off, sonst hätte ich mehr geschrieben . ;)
Habe gerade im Log gesehen:
ZitatPERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MYSENSORS_DEVICE.pm line 665.
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. :-[
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?
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...
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?).
Was soll ich sagen....
ich habe es aus deinem Code geliehen ::), da war es in presentation... ???
In setup funktioniert es. :)
Super, vielen Dank.
;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!)
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
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!?
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.
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?
Hmm, alle %-Werte auf einmal finde ich schwierig, das braucht relativ viel Auswertelogik beim Empfang der Nachricht. Würde das eher über getrennte Infos lösen.
Also, mal angenommen du hast bis 5 Kreise:
Dann nutzt du "Custom" (value1-value5 an - sagen wir - child 100), um für jeden der Kreise einen "Basiszeitwert" festzulegen. Optimalerweise würde ich einen Minutenwert oder 30-Sek.-Wert vorschlagen, dann kann der ohne allzugroße Umstände im EEPROM gespeichert werden (vorgesehen ist 1 BYTE/Child, da mußt du dann schon tricksen...), andernfalls holt sich die Node den bei jedem Start.
Dann definierst du einen Dimmer, mit dem kannst du "Notaus" und "an" mit einem Prozentwert einstellen.
Aus dem einen Prozentwert und den Minutenangaben machst du dann die Anschaltdauern (in millis) auf der Node (simple Mathematik), und kannst dann auch einzelne Kreise (child 1-5?) ein- und ausschalten. Schaltest du einen via FHEM oder lokalem Taster aus, wird einfach dann bei "generell-an" der nächste genommen, auch vor Zeitablauf usw..
Es gibt aber afaik auch schon einen sketch im MySensors-Forum. Müßte man sich mal ansehen, was der wie haben will (ich bastle dann auch gerne ein attrTemplate draus...).
Danke für die gedanklichen Anstöße. Ich merke ich muss noch mehr bedenken.
Ich habe einen Node mit 2 und einen mit 3 Kreise. Die Sprinkler sind noch nicht installiert und entsprechend habe ich noch keine Durchflussmenge pro Kreis. Daher weiß ich auch noch nicht wie ich sie zusammen, bzw. In welcher Reihenfolge ich sie betreibe, damit es mit der Brunnenpumpe harmoniert.
Ich werde es erstmal, wenn ich soweit bin, über Fhem die Zeiten steuern und wenn alles steht auf die Nodes übertragen. Bis dato wird es vermutlich nächsten Winter.
Eine Frage noch:
Ein sleep in Perl ist blockiernd, soweit klar. Wie verhält es sich mit Schleifen (while, for, etc.)?
Wenn ich z.B. über ein at eine sub in MyUtils starte und darin ist eine Schleife die mehrere Minuten dauert.
...ich glaube, diesen Thread sollte "jemand" mal splitten, ist ziemlich viel Zeug hier drin, das mit Stromversorgung nichts zu tun hat...
Zur Sache: Sorry, wenn ich das so deutlich sage, aber es gruselt mich, wenn ich lese, dass eine Schleife länger dauern soll. Es ist extrem wichtig, FHEM (genauer phem.pl) nicht zu blockieren, also sollte man alles auslagern, was länger dauert, entweder in einen separaten Prozess oder eben auf die Hardware, oder den Programmablauf nicht blockierend gestalten. Aber eine "Ereignisprüfungsschleife" mit while (so hatte ich das verstanden) ist mMn. unbedingt zu vermeiden.
Wie man was auslagert, wäre z.B. hier erläutert (oh Wunder, es geht um Gartenbewässerung...):
https://forum.fhem.de/index.php/topic,6436.msg26685.html#msg26685 (https://forum.fhem.de/index.php/topic,6436.msg26685.html#msg26685)
Wenn es innerhalb FHEM laufen soll, kann man (direkt oder indirekt) InternalTimer nutzen. Das braucht halt einen Funktionsaufruf. Ein Beispiel wäre (neben dem Suchwort Dimmer) z.B. in RandomTimer zu finden. RandomTimer_Exec ruft sich am Ende auch immer wieder selbst auf, nachdem es geprüft hat, ob es (wie) schalten muß und ermittelt dabei (mit RandomTimer_getSecsToNextAbschaltTest) den nächsten Zeitpunkt bzw., ob überhaupt noch ein Durchlauf erforderlich ist.
Ist mir gestern auch aufgefallen, dass das hier eigentlich zu OT ist. [emoji16]
Bzgl. Perl werde ich bei weiteren Fragen einen neuen Thread aufmachen.[emoji3]
Bezgl. Schleife habe ich vermutet, das es blockiert, wollte nur sicher gehen.
Den Rest werde ich mir anschauen und nach einer Guten Lösung suchen. Es gibt noch viel zu lernen....
Nochmals Danke für die Tipps [emoji3]
Wieder ein Stück weiter. :)
Den Betreff habe ich mal angepasst, da mittlerweile sehr viel dazugekommen ist.
Ich denke, ich habe die für mich optimale Lösung gefunden:
Die Zeitsteuerung der Relais läuft autark auf den Nodes.
Die Zeit kann nach Berechnung über Fhem (MyUtils) in einem "Rutsch" an die Nodes für alle Relays übergeben werden.
Danach wird das erste Relay geschaltet und über notify's (evtl. DOIF o.ä.) die restlichen Relais in bestimmter Reihenfolge nacheinander/parallel geschaltet.
Vielleicht hilft es jemanden, hier mein aktueller Code (falls es Verbesserungspotential gibt, immer her damit):
/**
The MySensors Arduino library handles the wireless radio link and protocol
between your home built sensors/actuators and HA controller of choice.
The sensors forms a self healing radio network with optional repeaters. Each
repeater and gateway builds a routing tables in EEPROM which keeps track of the
network topology allowing messages to be routed to nodes.
Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
Copyright (C) 2013-2015 Sensnology AB
Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
Documentation: http://www.mysensors.org
Support Forum: http://forum.mysensors.org
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
*/
/*
* Relays mit Zeitsteuerung (0-100 Minuten oder 0-100 Sekunden)
* Bei Reboot wird der letzte Status aus Fhem übernommen
*
* Bei Benutzung von z.B. einem MAX485 muss der DE-Pin deklariert werden
*
* Bedienung:
* 1. setzen der Laufzeit (Zeiten können alle vor den ersten Start gesetzt werden)
* 2. einschalten des/der Relays
*
*/
#define SN "TimerRelays"
#define SV "0.1"
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable RS485 transport layer
#define MY_RS485
// Define this to enables DE-pin management on defined pin
//#define MY_RS485_DE_PIN 2
// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 19200
// Enable this if RS485 is connected to a hardware serial port
//#define MY_RS485_HWSERIAL Serial1
#define MY_NODE_ID 2 // Id of the Node
#define MY_TRANSPORT_WAIT_READY_MS 3000 //loop is beginning at 3000ms whitout connection
#include <MySensors.h>
//++++++++ Relays +++++++++
#define RELAY_ON 1 // switch around for ACTIVE LOW / ACTIVE HIGH relay
#define RELAY_OFF 0
#define noRelays 3 // min 2
const int relayPin[] = {10, 11, 12}; // switch around pins to your desire
uint32_t relayTime[] = {0, 0, 0}; // on time for Relay to set from Fhem
volatile uint32_t startTime[] = {0, 0, 0}; // time to switch Relay on
const uint32_t timeFactor = 1000UL; // to send minutes = 60000UL or seconds = 1000UL; UL says compiler is unsigned long!!!
class Relay // relay class, store all relevant data (equivalent to struct)
{
public:
int relayPin; // physical pin number of relay
boolean relayState; // relay status (also stored in EEPROM)
uint32_t relayTime; // on time for Relay
uint32_t startTime; // time to switch Relay on
};
Relay Relays[noRelays];
MyMessage msgRelay[noRelays];
MyMessage msgTime[noRelays];
void before()
{
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo(SN, SV);
//++++++++ Relays +++++++++
for (int i = 0; i < noRelays; i++)
{
present(i, S_DIMMER); // present sensor to gateway
wait(20);
}
}
void setup()
{
//++++++++ Relays +++++++++
for (int i = 0; i < noRelays; i++) {
Relays[i].relayPin = relayPin[i]; // assign physical pins
Relays[i].startTime = startTime[i]; // assign time to switch relay on
Relays[i].relayTime = relayTime[i]; // assign time for relay on
msgRelay[i].sensor = i; // initialize messages
msgRelay[i].type = V_STATUS;
msgTime[i].sensor = i;
msgTime[i].type = V_PERCENTAGE;
pinMode(Relays[i].relayPin, OUTPUT);
Relays[i].relayState = RELAY_OFF; // set all relaysState off
digitalWrite(Relays[i].relayPin, Relays[i].relayState ? RELAY_ON : RELAY_OFF); // write all relays off
//send(msgRelay[i].set(Relays[i].relayState ? true : false));
wait(20);
}
for (int i = 0; i < noRelays; i++)
{
request(i, V_STATUS); // Set relay to last known state
wait(20);
request(i, V_PERCENTAGE);
wait(20);
}
}
void loop()
{
uint32_t currentTime = millis();
//++++++++ Relays +++++++++
//Zeitsteuerung der Relays
for (byte i = 0; i < noRelays; i++) {
if ( Relays[i].relayState == RELAY_ON && (currentTime - Relays[i].startTime > Relays[i].relayTime)) {
digitalWrite(Relays[i].relayPin, !Relays[i].relayState ? RELAY_ON : RELAY_OFF);
Relays[i].relayState = !Relays[i].relayState;
send(msgRelay[i].set(Relays[i].relayState ? true : false));
Relays[i].relayTime = 0;
send(msgTime[i].set(Relays[i].relayTime));
// save sensor state in EEPROM (location == sensor number)
//saveState( i, Relays[i].relayState );
#ifdef MY_DEBUG
Serial.print("relayTime reached:");
Serial.print(Relays[i].relayState);
Serial.print(" time: ");
Serial.println(Relays[i].relayTime);
#endif
}
}
}
void receive(const MyMessage &message) {
//++++++++ Relays +++++++++
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) {
Relays[message.sensor].startTime = millis();
}
#ifdef MY_DEBUG
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
#endif
}
if (message.type == V_PERCENTAGE) {
if (message.sensor < noRelays) { // check if message is valid for relays..... previous line [[[ if (message.sensor <=noRelays){ ]]]
Relays[message.sensor].relayTime = (message.getByte() * timeFactor); // calculate to millis
}
#ifdef MY_DEBUG
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New time: ");
Serial.print(message.getByte());
Serial.print(" (min|sec), millis: ");
Serial.println(Relays[message.sensor].relayTime);
#endif
}
}
Gruß und Danke für die Hilfe, ohne die ich soweit nicht gekommen wäre :)
Bernd