DS18B20 (+ RS485/CAN)

Begonnen von Schotty, 10 März 2020, 12:59:18

Vorheriges Thema - Nächstes Thema

Schotty

Moin zusammen,
dank @Beta_User hat mich jetzt das MySensors@RS485/CAN-Fieber wohl auch erwischt  ;D
Momentan ist noch nichts installiert, lediglich als Testaufbau auf dem Schreibtisch verkabelt. Die finale Installation (Nano als Node) soll dann im Keller die Wasseruhr auslesen. Meine dortige DS18B20-Installation (ca 9 Sensoren bisher, evtl kommen noch welche hinzu) lese ich bisher über unseren BSB-LAN-Adapter-Arduino mit aus, der für die Heizung zuständig ist. Dort muss ich die Sensoren jedoch regelmäßig abfragen.
Nun habe ich gesehen, dass es bei MySensors wohl möglich ist, automatisch bei Wertänderung die Temps zu schicken - das klingt super!
Meine Fragen sind jetzt:
1) Ist es problemlos möglich, den DS18B20-Sketch noch bei der Wasseruhr-Node hinzuzufügen? Oder müsste/sollte man dafür dann einen extra Nano einrichten?
2) Da es mir wichtig ist, die spezifische SensorID auszulesen um die Temps nachher eindeutig zuordnen zu können (und die Zuordnung somit dann auch nach einer Änderung der DS18B20-Installation noch passt, bspw wenn Sensoren entfernt oder hinzugefügt werden): Welchen Sketch sollte ich da nehmen? Ich habe hier
https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency
entspr Sketche gefunden, bin mir aber leider nicht sicher, welchen davon ich nun am Besten nutzen sollte.
Danke & Gruß
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Dann mal willkommen bei diesen Themen :) .

Also:

ad 1: Die DS18B20 brauchen zum Auslesen immer etwas Zeit.
Das kann man auf verschiedene Weisen umsetzen. Der "Standardsketch" von MySensors verwendet schlicht "sleep" (bzw. "wait") zwischen der Anweisung, die Messung auszulösen und der Abfrage der Werte. Je nach Auflösung ist das bis zu einer Sekunde.

a) Kombiniert man das mit dem Standard-WaterMeter-Sketch von MySensors, geht es, denn der verwendet einen Interrupt (=> das "sleep/wait" wird kurz unterbrochen und der Zähler hochgezählt, "void onPulse". Gesendet wird dann "irgendwann".
Voraussetzung ist ein digitales Signal.
Kurz: das geht, denn dein Sensor liefert ein solches 0/1-Signal...

b) aa) Will man das mit einer "normalen" PIN-Level-Abfrage kombinieren (z.B. weil kein Interrupt-fähiger PIN mehr frei ist), wird es - je nach Drehzahl - schwierig, denn das Signal muß lange genug on bzw. off sein, dass die Wartezeit nicht stört.

PeMue hat irgendwo mal Code gepostet, die das mit einer "non-blocking-loop" Methode löst; macht man das auf diese Weise, geht mit einiger Sicherheit auch das; Einschränkungen höchstens, wenn insgesamt zu viel gleichzeitig passieren soll, was jeweils für sich etwas dauert.

bb) Will man analog messen (irgendwo hier kompensiert jemand mit einer Analogmessung Umgebungslichteinflüsse und kalibirert den Sensor darüber...) geht es vermutlich gar nicht gut zu kombinieren; evtl. doch, wenn man die "non-blocking-loop" verwendet, aber das müßte man ausprobieren.

Die Schwierigkeit ist eher der Umbau des Codes insgesamt in eine "nicht-Schlafende" Variante (schlafen lassen finde ich bei R485-Nodes irgendwie nicht sooo zielführend), da kannst du dich aber gut an dem "SLEEP_MODE false"-Zweig im PulseWaterMeter-Sketch orientieren, und dabei dann ggf. darauf achten, dass du zwei Zyklen definieren müsstest, wenn der Temperatur-Teil "langsamer" senden soll.
Für den OneWire-Bus würdest du dann schlicht einen anderen PIN nehmen (PIN4, z.B.) und den "loop"-Teil eben ebenfalls in die "non-blocking-loop" aus dem pulse_water mit einbauen.

Ad 2:
In dem Repo sind zwei Ansätze vorgestellt, beides funktioniert:
a) der "Stored_ID"-Sketch ist für den Anwender mMn. der einfachere: Aus den vollen DS-Adressen werden Hashes abgeleitet und diese Hashes im EEPROM gspeichert. Beim Starten schaut der Arduino, ob er die Adresse kennt (also einen passenden Hash im EEPROM hat) und leitet daraus dann die ChildID ab. Solange der Sensor am Bus ist und kein anderer angesteckt wurde, kann man den ab- und wieder anstöpseln, wie man lustig ist - der und die anderen behalten ihre Position. Will man einen Sensor tauschen, stöpselt man einfach den einen ab, den anderen ein und startet die Node, schon bekommt man unter dieser ID die Daten vom neuen, die anderen bleiben, wo sie sind ;) . Sind alle Sensoren vorhanden, kommt ein neuer einfach an's Ende.
Man kann auch die Reading-Namen unter FHEM so vergeben lassen, dass die betreffende ID dort verwendet wird, es gibt dafür eine Funktion im FHEM-Modul ;) . (Das würde ich aber lassen, den Mehrwert sehe ich nicht so richtig). Besser ist es mMn., sich die ID im Rahmen von Setup() senden zu lassen.

Vermutlich ist der Speicherverbrauch bei diesem Sketchtyp etwas höher.

b) Man kann auch die Adressen "hart vercoden". Das ist die "Array-Solution"-Methode, die in meinen Echt-Sketchen typischerweise verwendet wird.
Der Sketch gibt "as is" erst mal nur das Array an sich aus, das man dann für den eigentlichen Code braucht. Dass da die Array-Solution vercoded ist, hat v.a. damit zu tun, dass es bei diesen Sketchen gleich mehrere PINs gibt, an denen funktional unterschiedliches "Zeug" hängt - teils noch mit unterschiedlichen Abfrageintervallen... (die Hash-Methode habe ich erst später entdeckt/verstanden, da war der Code für meine Nodes in den Grundzügen schon fertig und zum Umbau bestand keine Veranlassung, also habe ich das nach der Prinzip-Darstellung dann auf die Seite gelegt).

Ad "Senden bei Wertänderung":
Das ist bei dem "https://www.mysensors.org/build/temp" standardmäßig so eingestellt. Ich finde das nicht sooo glücklich, meine Senden nach einer Mindestzeit immer (3 bzw. 5 Min,. denke ich).

Wenn du also sowas mit unterschiedlichen Abfrageintervallen und Höchstdauern bis zur nächsten Sendung bauen wolltest, wäre das kein Problem, aber das aus meinen anderen Sketchen rauszudestillieren, ist vermutlich eher schwierig...
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

Schotty

Danke für die ausführliche Antwort!

Zu 1)
Bei dem originalen MySensors-Sketch für den Wasserzähler passt ja bei mir etwas noch nicht so richtig. Kurze Erklärung: Der scheint ja ursprünglich für bspw TEKT5000er geschrieben worden zu sein und berücksichtigt nicht den Umstand bei meinem Sensor, dass da auch mal für ein paar Stunden das Signal anliegt, ohne dass Wasser fließt (weil das Metallplättchen im Erfassungsbereich zum Stehen gekommen ist). Erste Tests haben gezeigt, dass dann ein bestimmter Wert (Reading 'flow1') irgendwie Quatsch anzeigt. Wäre jetzt prinzipiell erstmal nicht so das Problem, weil es mir mehr um eine Anzeige für den 'allgemeinen' Verbrauch als um die Anzeige des momentanen Durchflusses geht - aber um das besser zu verstehen wollte ich evtl auch nochmal den veränderten Code von @Matscher und aus dem MyS-Forum testen, der einen gleichen Sensortyp nutzt. Allerdings nutzt @Matscher einen Analogpin..
Fazit:
Nach deinen Erklärungen erscheint es mir dann letztlich so oder so unkomplizierter, dem DS18B20er-Geraffel im Fall der Fälle direkt einen eigenen Nano zu spendieren.. ;)

Zu 2)
Wenn auch nur irgendwie das 'Risiko' besteht, dass die Sensoren ihre Position wechseln, dann würde ich das gern ausschließen. Das hatte bei mir mit unserer BSB-LAN-Lösung (bevor wir die spezifische SensorID berücksichtigt haben) anfangs einiges an Verwirrung ausgelöst  ;D
Insofern erscheint mir momentan die Lösung mit dem 'hart vercoden' etwas attraktiver, aber dann werde ich sonst einfach mal beide Lösungen testen, wenn es soweit ist.

Bzgl Ausleseintervall/Senden-bei-Tempänderung:
Hmm, dann muss ich mir da nochmal Gedanken machen.
Interessehalber:
Spräche denn prinzipiell etwas gegen deutlich kürzere Intervalle (bspw 30Sek)? Wird das GW oder der Bus dann zu sehr 'belastet'? Noch wäre die Installation ja recht klein und überschaubar, aber wenn es dann irgendwann doch mal mehr wird mit Nodes und Sensoren..?

Zitat von: Beta-User am 10 März 2020, 14:24:02
Wenn du also sowas mit unterschiedlichen Abfrageintervallen und Höchstdauern bis zur nächsten Sendung bauen wolltest, wäre das kein Problem, aber das aus meinen anderen Sketchen rauszudestillieren, ist vermutlich eher schwierig...
Sprich: Das Intervall bei deinen Sketches betrifft dann die Abfrage ALLER Sensoren en block, richtig?
Heißt der oben zitierte Satz, dass es (jetzt nicht bei deinem Sketch sondern prinzipiell) aber auch möglich wäre, unterschiedliche Intervalle für einzelne DS18B20-Sensoren anzugeben, obwohl die alle am gleichen D0x-Pin angeschlossen sind?? Oder war das darauf bezogen, dass neben den DS18B20ern noch andere Sensoren angeschlossen sind? Vermutlich Letzteres, oder?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Vorab mal:

Sketche zu kombinieren, ist nach meiner Erfahrung nicht so kompliziert, wie es aussieht, man muß es einmal erfolgreich gemacht haben, dann wird es klarer... Und grade DS18B20 und Zähler sind geradezu prädestiniert ;D .

Zitat von: Schotty am 10 März 2020, 15:11:56
Zu 1)
Bei dem originalen MySensors-Sketch für den Wasserzähler passt ja bei mir etwas noch nicht so richtig.
Ich würde zwischenzeitlich eher auf ein schaltungstechnisches Problem tippen, weil die "INPUT_PULLUP"-Einstellung für den Interrupt-PIN (nach meinem Verständnis) davon ausgeht, dass das Signal sauber zwischen "to GND" und und "not to GND" wechselt. Du lieferst aber ein "high". Dass du jetzt Probleme hast, deckt sich mit der schon mal per Email mitgeteilten Vermutung, dass man einen pulldown-Widerstand zwischen PIN und GND einfügen sollte, damit eine eventuelle Restspannung sauber abfließt. Würde mal mit 10k ans Rennen gehen, bin aber - wie gesagt - kein Schaltungsexperte.
In der von mir getesteten 12V-Variante hatte ich einen Optokoppler (PC817) dazwischengeklemmt (Signal an PIN1 dort, PIN2 an GND des Sensors) und D3 (INPUT_PULLUP) -> PC817 (PIN 4) - PC817 (PIN 3) -> GND (Arduino). Das sollte denselben Effekt haben, wegen des nicht funktionierenden Sensors kann ich aber nicht sagen, ob das wirklich gegen Pseudoimpulse hilft...

Zu 2)
Teste es aus; mMn. ist beides hinreichend sicher, und wenn man "event-on-change" setzt, könnte man auch Änderungen der ID überwachen, wenn man sich die senden läßt (geht bei beiden Varianten). Ich hatte das mit den Hashes zwar nie intensiver getestet, aber bis zu 16 angeschlossen, und da hat das Tauschen einzelner Sensoren gut und zuverlässig funktioniert...

Ad Intervalle:
Prinzipiell sollte das kein technisches Problem sein, notfalls kannst du auch mit der Baudrate spielen (aber da sind wir bei 30 Sek. mMn. noch lange nicht). Es ist eher die Frage, für was man so viele Daten braucht... (Das war einer der Gründe, warum ich das auf mehrere Bus-PINs verteilt habe - für Außentemperaturen sind 5 Min schon eher kurz....)

Das mit den Intervallen ist - je nach Node - im komplexesten Fall so:
Die "requestTemperatures"-Anweisung geht immer auf den jeweiligen Bus, es messen dann also alle Sensoren an diesem Bus und stellen die Werte zur Abholung bereit. Welchen Sensor man dann tatsächlich abfragt, kann man getrennt davon entscheiden, ebenso natürlich, wann man ggf. einen neuen Wert versendet...

Vielleicht gliederst du mal deine Anforderungen, was du (unter welchen Voraussetzungen) eigentlich wissen willst.

Als Anregung vielleicht die paar Zeilen beginnend ab hier:
https://github.com/rejoe2/Heizung/blob/master/HeizungRS485/HeizungRS485.ino#L83

Bus 2 ist bei mir Ausgang vom Boiler + Rücklauf Warmwasser (vor der Umwälzpumpe):
- Abfrage alle 30 Sek (?), die Umwälzpumpe wird abgeschaltet, wenn ein bestimmter Wert erreicht ist (Leitung ist warm, Warmwasser steht zur Verfügung), Boilertemperatur wird gesendet (beides nur bei Änderung)
Bus 1 ist der Warmwasser-Ausgang (ca. 1m außerhalb der Therme):
- Abfrage alle 10 Sek (?), die Umwälzpumpe wird eingeschaltet, wenn ein bestimmter Wert erreicht ist, und die Leitung am Rücklauf nicht so warm, dass das keinen Sinn macht (Warmwasser soll schneller zur Verfügung gestellt werden), beides wird versendet (will ja wissen, was warum passiert ist).

Bus 0 sind dann Außentemperatur und Vor-/Rücklauf der Heizung:
Wird eben alle 5 Min. versendet, dto. ggf. geänderte Werte aus den anderen Messungen ab Bus 1 und 2.

(Der Code selbst ist zu vertrackt und ich habe auch insbesondere keinen Servo mehr dran, das hat mehr Probleme bereitet als es geholfen hat, aber v.a. wegen dem ist der Code so unübersichtlich...)

Übrigens: Es wäre auch kein großes Problem, der Node eine Anweisung zu schicken, dass im nächsten loop-Zyklus alles gemessen und übermittelt werden soll, falls man mal wirklich "sehr aktuelle" Temperaturen benötigt...
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

Schotty

Zitat von: Beta-User am 10 März 2020, 16:11:28
Ich würde zwischenzeitlich eher auf ein schaltungstechnisches Problem tippen, weil die "INPUT_PULLUP"-Einstellung für den Interrupt-PIN (nach meinem Verständnis) davon ausgeht, dass das Signal sauber zwischen "to GND" und und "not to GND" wechselt. Du lieferst aber ein "high". Dass du jetzt Probleme hast, deckt sich mit der schon mal per Email mitgeteilten Vermutung, dass man einen pulldown-Widerstand zwischen PIN und GND einfügen sollte, damit eine eventuelle Restspannung sauber abfließt. Würde mal mit 10k ans Rennen gehen, bin aber - wie gesagt - kein Schaltungsexperte.
Den PULLUP hatte ich wie per Email mitgeteilt entfernt, ich glaube ich hatte auch die von dir vorgeschlagene zusätzliche Variante mit dem Pulldown getestet, weiß es aber gerade nicht mehr so ganz genau (da war einfach zuviel Gebastel in der letzten Zeit ;) ), werde ich auch nochmal testen.
Prinzipiell werden die Impulse als solche jedoch bereits einwandfrei erkannt (auch, wenn das Signal länger anliegt und dann wieder entfällt) und entspr bei 'value11' und 'vloume1' korrekt gezählt. 'Pseudoimpulse' sind also anscheinend nicht das Problem.
Das, was nicht passt ist wie gesagt die 'flow'-Geschichte, das wird vermutlich(!) im Code anhand der Durchflussrate und Zeit der aktuelle Durchfluss berechnet.

Danke für die Ausführungen auch bzgl Punkt 2.
Zitat
Vielleicht gliederst du mal deine Anforderungen, was du (unter welchen Voraussetzungen) eigentlich wissen willst.
Werde ich dann tun, bisher ging es mir eher um die allgemeinen Rahmenbedingung/Möglichkeiten, daher hatte ich das auch eher 'generell/prinzipiell' formuliert.

Zitat
Als Anregung vielleicht die paar Zeilen beginnend ab hier:
https://github.com/rejoe2/Heizung/blob/master/HeizungRS485/HeizungRS485.ino#L83
Danke, werde ich mir auch nochmal durchlesen.
Heizungsparameter, TWW-&AT-Temps etc kommen ja soweit verfügbar bereits via Heizungsadapter. Ich habe nur zusätzlich noch ein paar DS18B20er verteilt, bspw VL/RL HK, VL/RL Solar, TWW-Speicher unten etc.pp.
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Hmm, auf die Schnelle kommt mir der Code zu "flow" jetzt auch undurchsichtig vor, da hatte ich lange nicht reingesehen (und bisher auch keine Grafiken draus gebastelt)...
Soll wohl sowas sein wie eine Momentaufnahme der Zeit zwischen den letzten zwei Pulsen, aber irgendwie glaube ich nicht so recht, dass das Sinn macht, eigentlich sollte man wenigstens sowas wie Zeitscheiben von ein paar Sekunden haben, oder? (Wäre aber sehr viel komplexer zu ermitteln und dann mMn. besser in loop aufgeboben. Vielleicht macht das auch mehr Sinn, wenn man langsamere Pulse hat oder was, was etwas gleichmäßiger strömt, wenn es denn strömt (Gas, z.B.).).

Was die zusätzlichen DS18B20 angeht, würde ich dann einen Bus vorschlagen, da Messung alle 30 Sekunden oder 1 Min, senden, was mehr wie 1° Änderung ist, sonst alle 5 Minuten? Kann man aber auch auf der FHEM-Seite abfangen, mit event-on-change und event-min-interval? 30 Sek. würde zum Pulse-Meter passen => sehr einfach umzusetzen...
(Wenn mehrfaches von 30 Sek. gewünscht: einfach einen counter einfügen, der innerhalb der "Zähler-Zeit abwarten ist um" - Bedingung (nach lastSend=currentTime;)- erhöht wird; dann weiter unten den counter abfragen: 4x durch = 2 Minuten: Temps messen und senden, Zähler zurücksetzen.
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

Schotty

Zitat von: Beta-User am 10 März 2020, 17:11:40
Hmm, auf die Schnelle kommt mir der Code zu "flow" jetzt auch undurchsichtig vor,
Danke  ;)

Zitat
Soll wohl sowas sein wie eine Momentaufnahme der Zeit zwischen den letzten zwei Pulsen, aber irgendwie glaube ich nicht so recht, dass das Sinn macht, eigentlich sollte man wenigstens sowas wie Zeitscheiben von ein paar Sekunden haben, oder?
Ich weiß nicht, wie das bei anderen Zählern (mit mehreren Zeigern für die unterschiedlichen Durchflussmengen?) ist. Da irgendwo im Code (hab ihn grad nicht offen) aber auch irgendwo ein Wert bzgl Durchflussmenge (ich glaube es war 40l/min oder so) angegeben werden kann, gehe ich momentan davon aus, dass das mit 'flow' eben in Richtung momentaner Durchfluss geht. Würde so gesehen ja auch Sinn machen, da man damit natürlich auch eine gewisse 'Überwachung' realisieren könnte..

Zitat
Was die zusätzlichen DS18B20 angeht, würde ich dann einen Bus vorschlagen, da Messung alle 30 Sekunden oder 1 Min, senden, was mehr wie 1° Änderung ist, sonst alle 5 Minuten?
Was meinst du jetzt mit "einen Bus"? Da steh ich grad auf dem Schlauch..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Zitat von: Schotty am 10 März 2020, 17:25:06
Ich weiß nicht, wie das bei anderen Zählern (mit mehreren Zeigern für die unterschiedlichen Durchflussmengen?) ist. Da irgendwo im Code (hab ihn grad nicht offen) aber auch irgendwo ein Wert bzgl Durchflussmenge (ich glaube es war 40l/min oder so) angegeben werden kann, gehe ich momentan davon aus, dass das mit 'flow' eben in Richtung momentaner Durchfluss geht. Würde so gesehen ja auch Sinn machen, da man damit natürlich auch eine gewisse 'Überwachung' realisieren könnte..
Vermutlich. Wobei auch für eine Überwachung eine reine 1-Puls-Basis mMn. etwas wenig ist. Kann man auch anders machen:
Irgendwo in meiner Kellerkiste (*grins*) liegen auch noch ein paar Philips-Uhrenbausteine rum. Die können im Hintergrund interrupt-basiert zählen und man kann einen Alarm einbauen, wenn ein einstellbarer Wert an Pulsen überschritten ist. Mit diesem Alarm könnte man dann den Arduino "wecken" oder alarmieren (Wollte ich mal in eine Wetterstation einbauen, die dann ggf. Sturmwarnung macht... Das Ding bleibt aber bis auf weiteres in der Kellerkiste, ist mir grade too much... (Wobei: sooo schiwerig dürfte das ja eigentlich gar nicht sein *LOL*).

Zitat
Was meinst du jetzt mit "einen Bus"? Da steh ich grad auf dem Schlauch..
Schlicht: alle an einen PIN anschließen, nur eben nicht PIN3, da hängt ja der Wasserzähler dran... Ganz nach der Prinzipzeichnung hier: https://www.mysensors.org/build/temp
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

Schotty

Jaja, deine Schatzkiste - da würde ich ja wirklich gerne mal drin wühlen  ;D

Achsoo - ok, jetzt habe ich verstanden, was du mit 'einen Bus' meintest..
Ja, ich habe sowieso alle DS18B20er an einem Bus am Adapter-Ardu hängen, den würde ich dann einfach umklemmen (hier ganz unten siehst du meinen 'Verteilerkasten': https://1coderookie.github.io/BSB-LPB-LAN/kap12.html#1232-hinweise-zu-ds18b20-temperatursensoren).
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Jau, sieht doch gut aus.

Du könntest zum Testen einfach mal den "stored ID" nehmen und den auf RS485 adaptieren bzw. praktisch einfach die betreffenden Teile in den Zähler-Sketch einbauen.

Dazu einfach "alles" bis auf das, was den Transportlayyer betrifft 1:1 (in die jeweiligen Sektionen des Zähler-Sketches hinein) übertragen, und nur
- PIN3 zu PIN4 ändern (Zeile 43 in meinem Sketch) und
- das, was in loop direkt steht (ab Zeile 108), mal in die loop des pulse-counters einfügen, dort unmittelbar vor "if (!pcReceived) {" (nur Zeile 128 fällt selbstredend weg).

... dann sollte das schon lüppen...

(Den Inhalt meiner Kellerkiste kennst du jetzt schon fast komplett, btw..)
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

Schotty

Werde ich testen, danke für die entspr Hinweise.

..das mit deiner Schatzkiste wage ich allerdings zu bezweifeln  ;D
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

PeMue

Hallo zusammen,

Zitat von: Beta-User am 10 März 2020, 14:24:02
ad 1: Die DS18B20 brauchen zum Auslesen immer etwas Zeit.
Das kann man auf verschiedene Weisen umsetzen. Der "Standardsketch" von MySensors verwendet schlicht "sleep" (bzw. "wait") zwischen der Anweisung, die Messung auszulösen und der Abfrage der Werte. Je nach Auflösung ist das bis zu einer Sekunde.
ich hatte mit dem vitotronic Sketch ähnliche Probleme:
- der Webserver setzt alle 5s eine serielle Botschaft von WLAN auf seriell um und
- parallel sollen bis zu 5 1-wire Sensoren ausgelesen werden.
Ich habe das mit einer State Machine gelöst, siehe hier:
https://forum.fhem.de/index.php?action=dlattach;topic=51583.0;attach=131291
Da ist wie beim blink_w_o_delay Sketch verschiedene Stati, die einfach schauen, ob der Task schon fertig ist/sein kann, falls nicht, geht es mit der Bearbeitung weiter und der Status wird am Ende umgeschaltet für den nächsten Teilschritt. Somit wird nichts (wesentlich) blockiert ...
Nur so als Anregung  ;).

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

 :)
Was für eine schön aufgeräumte loop!
Da sieht man den Könner!

Zwischenzeitlich würde ich den ganzen Code in den meisten meiner Nodes etwas anders aufbauen und vermutlich für die gemischten Sketches
- bei Bedarf sowas wie "Timer" nutzen und
- den "eigentlichen Code" für die Sensorabfragen usw. in weitere .h/.c-Files auslagern und die dann einbinden. Der Code sollte dadurch deutlich besser lesbar werden...

(Aber man lernt ja nie aus...)

Zitat von: Schotty am 10 März 2020, 18:05:53
..das mit deiner Schatzkiste wage ich allerdings zu bezweifeln  ;D
Habe gestern noch nach diesen dusseligen Lasern gesucht (erfolglos, heute morgen ist mir dann eingefallen, wo die sind...), und bei der in der Kiste durchaus intensiven Suche folgende Feststellungen gemacht:
1. Du kennst den Inhalt meiner Kellerkiste wirklich weitgehend, da fehlen nur noch ein paar "Kleinigkeiten" (max. 10 Sensortypen oder so  :P , das meiste für das nie wirklich begonnene "universalistische solarbetriebene Wetterstationsprojekt" - UV, Hintergrundtemperatur per IR-Messung...) und eben Kleinteile wie Widerstände usw..
2. hatte noch einen einstellbaren Reedkontakt rumliegen; der wird dann am Wasserzähler als nächstes getestet, vielleicht ist der sensibel genug ??? .
3. Habe ich vermutlich einfach die falsche Type Näherungssensor verwendet (habe schon nachgeordert, der Reed ist erst danach aufgetaucht ::) ).
4. "Jemand" sollte mal aufräumen  ;D ;D ;D ...
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

Schotty

@PeMue: Auch dir danke für deine Antwort und deinen Sketch! Das ist zwar auf den ersten Blick noch etwas zu hoch für mich, aber irgendwann verstehe ich auch sowas hoffentlich mal :D

@Beta-User: Also bei deinem Typ Wasseruhr wage ich zu bezweifeln, dass das mit einem Näherungssensor überhaupt funktioniert - der erfasst ja Metall, die kleinen roten Zeiger sind aber doch aus Plastik  :o
..aber dann landet der notfalls eben in deiner Kiste - irgendwann kannste ihn bestimmt mal gebrauchen  ;) (Btw: Ist das der, den ich auch habe und dir die Bezeichnung mal geschickt hatte? 8mm, PNP NO & 5V?)

Aber nochmal ganz kurz back to topic:
Wenn ich die hash-Version flashe und zum Testen am Schreibtisch erstmal ein paar andere DS18B20er anschließe, die später aber ja nicht daran zum Einsatz kommen - kann/soll ich dann das EEPROM vor der 'finalen' Verwendung nochmal mit dem MyS-Lösch-Sketch plätten und dann den eigentlichen Sketch nochmal frisch flashen, damit die Test-DS18B20er wieder aus dem EEPROM gelöscht sind..? Macht das Sinn..?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

PeMue

Zitat von: Beta-User am 11 März 2020, 10:36:50
:)
Was für eine schön aufgeräumte loop!
Da sieht man den Könner!
Danke für die Blumen, das meiste war eher copy & paste in Verbindung mit etwas Nachdenken. Und der Ausgabe, wieviele Millisekunden in der jeweiligen Schleife "verbraucht" werden ...

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

@PeMue:
Das war eher ein "interner Witz" mit Schotty: Er meinte irgendwo anders, meine Sketche sähen nicht unbedingt so aus, als stammten sie von einem "hobbyisten"... Sind aber im wesentlichen auch nicht viel mehr wie c&p+etwas Nachdenken - und wie man sieht, auch nicht unbedingt auf eine Weise aufgeräumt, die "fortgeschrittenere hobbyisten" empfehlen würden ::) .

[OT]
Bei der Uhr müßte es irgendwo (in der Mitte/der Nähe der Mitte, weg von den Zeigern?) auch was metallisches geben, evtl. auch was magnetisches (so jedenfalls die Hoffnung). Da ich 12V habe und die Schaltung mit dem Optokoppler auch funktioniert, habe ich die 8-mm-12V bestellt (ist: 4mm - hätte ich auch früher drauf kommen können, dass das schlicht der falsche Typ ist...).

Und ja: Alternativ setze ich die für das Garagentor ein ;) . Das mit den 12V am Signalausgang ist bei größeren Kabellängen "gefühlt besser" als nur 5V...
[/OT]

Zum Sketch:
Doku sagt, dass der Sketch so gestrickt sei, dass er bei Start ohne DS18B20 das EEPROM säubert => das ist zur späteren Deaktivierung nach dem Rumgeteste gedacht, ohne dass man irgendeinen anderen Sketch benötigt ;D ...

Ansonsten gilt: Wenn ein gespeicherter DS18B20 nicht gefunden wird, aber was anderes angeschlossen ist, wird überschrieben. Es sollte also reichen, schlicht das Teil nach dem Testen umzuziehen ;) . No further action required... (Hatte ich nicht geschrieben, dass der Sketch aus Anwendersicht einfacher zu handhaben sein müßte *kopfkratz*)?
(Trotzdem das "Autolöschen" bitte deaktivieren, und möglichst alle "auf einen Rutsch" anschließen, dann entspricht nämlich die Reihenfolge im EEPROM dem, was nach dem Kompletten Löschen passiert => ist näher an dem was passieren würde, wenn man den Arduino tauschen muß; erst wenn beides nicht mehr 1:1 übereinstimmt, ist die Array-Lösung dann am Ende doch besser ;) ).

Nimm einfach mal 3 DS18B20, lass dir die ID's schicken und beobachte, was passiert, wenn du mit den Teilen rumspielst, alle anstöpselst, nur einen Teil, andere, dazwischen keinen, dann alle nacheinander einzeln hinzufügen...
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

Schotty

Zitat von: Beta-User am 11 März 2020, 12:59:33
Zum Sketch:
Doku sagt, dass der Sketch so gestrickt sei, dass er bei Start ohne DS18B20 das EEPROM säubert => das ist zur späteren Deaktivierung nach dem Rumgeteste gedacht, ohne dass man irgendeinen anderen Sketch benötigt ;D ...
Perfekt! Der Mann hat ja mal wieder an alles gedacht  ;D

Zitat
Ansonsten gilt: Wenn ein gespeicherter DS18B20 nicht gefunden wird, aber was anderes angeschlossen ist, wird überschrieben. Es sollte also reichen, schlicht das Teil nach dem Testen umzuziehen ;) . No further action required... (Hatte ich nicht geschrieben, dass der Sketch aus Anwendersicht einfacher zu handhaben sein müßte *kopfkratz*)?
Doch, hattest du geschrieben, habe ich auch gelesen - ich wollte nur nochmal auf Nummer sicher gehen (dass ich den Teil ja richtig verstanden habe) und habe daher nachgefragt.. Kommt bei mir (leider) öfter mal vor..  ::)

Zitat
(Trotzdem das "Autolöschen" bitte deaktivieren, und möglichst alle "auf einen Rutsch" anschließen, dann entspricht nämlich die Reihenfolge im EEPROM dem, was nach dem Kompletten Löschen passiert => ist näher an dem was passieren würde, wenn man den Arduino tauschen muß; erst wenn beides nicht mehr 1:1 übereinstimmt, ist die Array-Lösung dann am Ende doch besser ;) ).
Ich werde am Schreibtisch testen und habe dann final ja eh nur das eine Buskabel anzuschließen, an dem bereits alle Sensoren angeschlossen sind. Irgendwann kommt dann vielleicht nochmal einer hinzu oder entfällt (wenn ich denn endlich mal meinen anderen Solarregler angeschlossen und mit meiner Heizungssteuerung verheiratet habe - aber du kennst das ja, man kommt einfach zu nichts  ;D ), aber das wird dann ja auch funktionieren..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/