Doppelnutzung von DS18B20 Temperatursensoren

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Der verlinkte Beitrag von Harald Sattler ist ja interessant.

      Ich habe hier 4 solche Module ZS-042 mit verbautem DS3231SN-Chip. Also die Temperatur-Kompensierten Dinger, wo auch die Kapas per Register zu- oder weggeschaltet werden können.

      Ich hatte meine Module vor Jahren mal bei eBai besorgt und auf Halde gelegt.
      So sehen die Module aus: ZS-042

      Die Module haben einen Pin "32K" genannt und auch diesen ominösen SQW-Pin.
      Ohne I2C-Bus nur eingesteckt (keine Batterie) und geschaut was da an diesen Pins raus kommt.
      Der SQW muss man einschalten, also am 32K Pin geschaut.

      Und siehe da, 32,7689kHz bei allen 4 Modulen.

      Wenn der Fehler also jetzt nicht durch das viele Auslesen der Register passiert, müssten ja diese Module korrekt laufen.

      Woran kann man denn erkennen, ob diese DS3231 wirklich von Dallas oder Maxim sind und nicht von einem Fake-Produzent?
      Auf dem Chip ist ja vermutlich noch ein Herstellungscode und ein Chargencode aufgedruckt?

      Auf all meinen Modulen findet sich bei der Beschriftung unten links noch ein Doppelkreuz '#'.
      Was hat es damit auf sich?

      Ich sehe gerade, das # scheint eine Hinweis auf RoHS-Status zu sein.

    • Wenn bei mir was ungenau waren dann die DS1307, mit den DS3231 hab ich null Probleme, die laufen von Sommer zu Winterzeit und umgekehrt nichtmal ne Minute falsch. Und ich frag die sekündlich ab. Mal irgendwo und irgendwann bei bei Ebay und Chinamann bestellt. Ich fahr die aber auch alle mit dem Umbau auf keine Ladeschaltung quf normale 3032 batterie
      Kann natürlich sein das inzwischen auch gefälschte unterwegs sind, der billigheimer ch340 seriell wird ja wohl auch so massiv gefälscht das der Hersteller nun den Treiber modifiziert hat der die blockiert.

      Tobias

    • Ich komme doch nochmal auf die DS3231-RTC Module zurück:

      Habe gerade zwei dieser Module bei gleichem Stecker, gleichem Programm, am UNO verglichen.
      Das linke Modul hat exakt 32,768kHz, das rechte hat 32,684kHz. Bei mehrmaligem Umstecken immer das gleiche Bild.

      Auffällig ist, dass bei dem linken "guten" Modul die Standardkerbe auf der vordern Strinseite vorliegt, während sie bei dem rechten Modul nicht vorhanden ist. Ob das ein Hinweis auf ein Fake-IC ist?

      Gruß
      Ulrich
      Files

    • ich habe mich eine Weile nicht gemeldet, weil ich mit der Hardware nicht weiter kam. Vor allem aus Zeitgründen ...
      Heute aber ein Stück: in einer der drei Phasen wird per CT der Strom gemessen, in einem Messgleichrichter in einen Gleichspannungswert verwandelt und an den Shelly Uni zur AD-Messung übergeben. Ich weiß, ist nicht Bascom, aber so kann ich mir die ca. Leistung der WP immer auf dem Handy anzeigen lassen, zusammen mit den vier Temperaturwerten. Heute konnte ich dank neuer Basisplatine auch mal am 1-Wire zwischen Shelly und Sensoren "sniffen" und weiß jetzt, wie die Abfrage der Temperaturwerte vonstatten geht: für die Wandlung und nachfolgende Wertabfrage braucht das System aus Shelly und 4 Sensoren DS18B20 ziemlich genau 530ms. Dann ist die Datenleitung wieder dauerhaft high. Die Abfrage erfolgt nur alle 5s, so daß mir genug Zeit bleiben sollte (immerhin knapp 4,5s), einen eigenen Abfragebefehl an die Sensoren zu schicken. Ich weiß nur noch nicht, ob der "Shelly Master" es erträgt, wenn ich "ihm" die Leitung "low pulle" und eigene Befehle über die Leitung zu den Sensoren schicke. Das muß ich einfach testen, denke ich. Wenn es Probleme gibt, dann bleibt mir wohl nur der Einsatz des oben schon erwähnten Multiplexers. Evtl. überbrücke ich beide Eingänge des Multiplexers und den Ausgang dann noch mit einem hochohmigen Widerstand von je ca. 100kOhm, damit es garantiert kein "Umschaltknacken" gibt und der Pegel "für alle Beteiligten lesbar" sauber auf H bleibt. Auch da muß ich schauen, ob das nötig werden wird.

      Zur RTC kann ich noch sagen, daß ich mir (neben anderen) ein Modul mit dem Chip DS3231M gekauft habe: Das Modul ist ziemlich klein und scheint (jedesfalls laut Datenblatt des M) eine Primärbatterie direkt an einem Pin des IC dran zu haben. Eine Diode und einen Ladewiderstand gibt es auf dem Modul nicht*, so daß man hier keine Angst vor evtl Überladung oder Blähung haben muß. Aber andereseits ist natürlich auch die Batterie ziemlich klein und ich weiß nicht, wie lange die es wohl machen wird. Wenn sie "tot" ist, muß ich sie auslöten und spätestens dann werde ich wohl eine 2032 Halterung und entsprechend große Zelle als Ersatz vorsehen.
      (*) wohl aber 2 Pullup-Widerstände von je 4.7k an SDA und SCL, ein feature, daß zB mein GLCD Display nicht hat!
      Wie läuft das eigentlich genau ab zwischen den µC und der RTC, wird da eine Ganzzahl vom µC in dem Moment an die RTC übermittelt, wo man dd.mm.yyyy und hh:mm:ss eingegeben hat? Oder werden tatsächlich dd, mm, yyyy, hh, mm, ss EINZELN an die RTC geschickt, damit sie sich diese merkt und weiterzählt?
      Hat jemand einen schönen Codeschnipsel für die Nutzung dieser RTC mit DS3231 für mich, damit ich nicht lange suchen muß? Mit (Erst)einstellungsmöglichkeit von Zeit und Datum per Tastern nach dem Booten? Das wäre toll!

    • In der Rtc liegen die Daten einzeln im Bcd Format. Die Figure 1 im Datenblatt zeigt das schön übersichtlich.
      Es ist doch Sinn der Sache sie eben nicht nach dem Booten einstellen zu müssen ;)
      Dieser Code zeigt eine Möglichkeit: DS3231_RTC_stellen.bas
      Einfacher geht es mit einer lib :ds1307clock.zip
      Damit wird sie automatisch gelesen/beschrieben sobald die Variablen im Code verwendet werden.

    • laase wrote:

      Eine Diode und einen Ladewiderstand gibt es auf dem Modul nicht*, so daß man hier keine Angst vor evtl Überladung oder Blähung haben muß. Aber andereseits ist natürlich auch die Batterie ziemlich klein und ich weiß nicht, wie lange die es wohl machen wird. Wenn sie "tot" ist, muß ich sie auslöten und spätestens dann werde ich wohl eine 2032 Halterung und entsprechend große Zelle als Ersatz vorsehen.
      Warum hast du nicht gleich die gekauft mit der CR2032-Halterung?

      laase wrote:

      Wie läuft das eigentlich genau ab zwischen den µC und der RTC, wird da eine Ganzzahl vom µC in dem Moment an die RTC übermittelt, wo man dd.mm.yyyy und hh:mm:ss eingegeben hat? Oder werden tatsächlich dd, mm, yyyy, hh, mm, ss EINZELN an die RTC geschickt, damit sie sich diese merkt und weiterzählt?
      Normalerweise hat die RTC eine Batterie und läuft damit unabhängig vom Controller.
      Wird der Controller resettet, wird eigentlich nur die Uhrzeit gelesen, wenn sie gebraucht wird.
      Die RTC muss hier nicht jedes mal gestellt werden, wenn der Controller einen Reset bekommt.
      Die RTC wird nur dann gestellt, wenn man eine neue Batterie eingelegt hat oder die Zeit/Datum nicht stimmt.

      Je nach Anwendung macht es vielleicht Sinn, die Uhrzeit nicht im Sekundentakt vom RTC auszulesen.
      Bei einer Uhr würde eine Synchronisation alle 24 Stunden vermutlich reichen.
      Daher gibt es mehrere Lösungsansätze, wie man mit der RTC umgeht.

    • Hallo @Pluto25
      hab supervielen Dank für diese Beispiele! Ich habe mir jetzt erlaubt, den Code aus dem ersten Beispiel dahingehend zu ändern, dass keine Eingabe über RS232 erfolgt, sondern einfach ein zuvor in den Code-header eingetragener String (Konstante) als Datums- und Zeitwert übernommen wird. Das reicht mir völlig, denke ich. Wie ja hier schon oft gesagt wurde, ist die Ganggenauigkeit für mich absolut ausreichend. Wenn es denn wirklich eine neue Zeit sein soll, dann kann ich auch per "Brennen" eine neue Zeit einstellen.
      Hier mein Code: (zu lang, daher Datei angehängt : Uhrzeit_uebernehmenV3.bas )

      Danke auch @Mitch64! Ich habe mir natürlich auch solche RTC mit CR2032 Halterungen bestellt, waren aber nicht so schnell da ;) Mittlerweile aber schon, nun könnte ich es mir aussuchen ... aber die minikleine RTC mit der aufgelöteten Batterie gefällt mir auch gut ... ich werde wahrscheinlich erst einmal diese drinlassen.
      Die Uhrzeit wird bei mir später wahrscheinlich einmal im 5s-Takt aus der RTC ausgelesen werden. Das ist die gleiche "Umlauffrequenz", wie ich auch zB die oben beschriebenen Temperatursensoren abfrage.

    • Ich brauche aber doch nochmal eure sehr geschätzte Hilfe bei dem ursprünglichen Thema: der "Doppelnutzung von DS18B20 Sensoren". Ich bekomme zwar einen Sensor abgefragt und kann dessen Temperatur auslesen und anzeigen, dann hängt das Programm aber (auch die Uhrzeitanzeige bleibt stehen) und es folgen keine weiteren Auslesungen mehr.

      Ausgangssituation ist ja nach wie vor, dass der Shelly Uni am 1W-Bus den Befehl "Temperatur Wandeln" ausgibt und nach der Wandlungszeit die Sensoren alle einzeln anhand ihrer Adresse (8 Byte Rom, inkl. Family Code als 1. Byte und CRC als letztes Byte) abfragt. Ich brauche mich nun also einfach nur "dahinter zu hängen", warte also ab, bis der Shelly den Bus "frei gemacht hat" (das ist bei mir nach ca. 550ms der Fall) und sende dann mit etwas zeitlichem Abstand mit dem Atmel noch einmal den Abfragebefehl - so zumindest der Plan. Zeit habe ich genug, denn der Shelly Uni fragt die Sensoren nur alle 5,0s ab.
      Folgendes kam aus dem Logic Analyzer searchresultsDS18B20Messung_6s_lang.txt . Ich ziehe im Folgenden mal die Zeilen raus, die ich für relevant halte und kommentiere sie:
      0.001580125000000,1-Wire,DATA: [68] Anm: ist das gleiche wie &H44 (Befehl zur Temperaturmessung)
      ....
      0.483921875000000,1-Wire,RESET condition
      0.484438750000000,1-Wire,PRESENCE condition
      0.484895625000000,1-Wire,MATCH ROM command: [85] Anm: ist das gleiche wie &H55 deckt sich also mit der bekannten Befehlszeile: 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      0.485481750000000,1-Wire,FAMILY CODE section from ROM: [40] Anm: ist das gleiche wie &H28 bzw &B00101000, aber ich weiß noch nicht, wo ich das "einbauen" muß
      0.486075250000000,1-Wire,ROM CODE section from ROM: [66421506205798] Anm: ist das gleiche wie &H3C68 F648 6866 (6 Bytes) bzw &B (sehr lang), aber ich weiß noch nicht, wo ich das "einbauen" muß
      0.489588500000000,1-Wire,CRC section from ROM: [209] Anm: ist das gleiche wie &HD1 bzw &B11010001, aber ich weiß noch nicht, wo ich das "einbauen" muß


      'Anm: Das ist der komplette "64-Bit Lasered ROM Code", gesendet als LSB first
      'auch im Datenblatt steht das so "When reading the scratchpad, data is transferred over the 1-Wire bus starting with the least significant bit of byte 0."


      0.490174750000000,1-Wire,DATA: [190] Anm: ist das gleiche wie &HBE bzw &B10111110 und deckt sich mit der bekannten Bef.Zeile: 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      0.490755125000000,1-Wire,DATA: [241] 241 ist &HF1; 241 (/16) wäre aber auch 15,06°C -> denkbare Temperatur! (ich tippe auf Vorlauf) -> Byte 0 (Tempwert LSB)
      0.491339500000000,1-Wire,DATA: [0] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 1 (Tempwert MSB)
      0.491926125000000,1-Wire,DATA: [85] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 2 (Userbyte 1)
      0.492512625000000,1-Wire,DATA: [5] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 3 (Userbyte 2)
      0.493099125000000,1-Wire,DATA: [127] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 4 (ConfigRegister)
      0.493685625000000,1-Wire,DATA: [165] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 5 ("Reserved"; bei Maxim &HFF)
      0.494272250000000,1-Wire,DATA: [165] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! -> Byte 6 ("Reserved")
      0.494858750000000,1-Wire,DATA: [102] Anm: Antwort (Byte) ist gleich wie beim nächsten Sensor! 102 ist &H66 -> Byte 7 ("Reserved"; bei Maxim &H10)
      0.495445250000000,1-Wire,DATA: [43] 43 ist &H2B -> Byte 8 (CRC)

    • (ich habs mal unterteilt, damit ich hier nicht wieder in die 1000 Zeilen (Wörter?) Grenze komme ...)
      Der Rom Code lässt sich also 1:1 aus dem Log File entnehmen und daraus habe ich jetzt Folgendes an Code für die Auslesung abgeleitet:

      Source Code

      1. '********Arrays und Variablen für die Tempsens-Kommunikation ***********************
      2. Dim N As Byte 'Zählvariable für das 1-Wire Timing
      3. Dim I As Byte 'Zählvariable für die Komm. am 1-Wire Bus
      4. Dim Dsid_vorlauf(8) As Byte 'Dallas ID 64 bits incl CRC
      5. 'siehe Kommunikationsprotokoll hat die Id Nr. die Bestandteile:
      6. '(
      7. FAMILY CODE section from ROM: [40] Anm: ist &H28 bzw &B00101000
      8. Code Section From Rom : [66421506205798] Anm : Ist &H3C68 F648 6866(6 Bytes) Bzw &B
      9. CRC section from ROM: [209] Anm: ist das gleiche wie &HD1 bzw &B11010001
      10. ')
      12. 'da die Daten in dieser Form zum Sensor geschickt werden: For I = 1 To 8 : 1wwrite Dsid2(i) : Next I vermute ich, daß ich die Bytes so anordnen muß (auf jeden Fall Family zuerst und CRC zuletzt)
      13. Dsid_vorlauf(1) = &H28 'Family
      14. 'Dsid_vorlauf(2) = &H3C
      15. 'Dsid_vorlauf(3) = &H68
      16. 'Dsid_vorlauf(4) = &HF6
      17. 'Dsid_vorlauf(5) = &H48
      18. 'Dsid_vorlauf(6) = &H68
      19. 'Dsid_vorlauf(7) = &H66
      20. Dsid_vorlauf(8) = &HD1 'CRC
      21. 'das hat nicht geklappt, daher jetzt hier eine umgekehrte Reihenfolge der Bytes zwischen Family Code und CRC:
      22. Dsid_vorlauf(7) = &H3C
      23. Dsid_vorlauf(6) = &H68
      24. Dsid_vorlauf(5) = &HF6
      25. Dsid_vorlauf(4) = &H48
      26. Dsid_vorlauf(3) = &H68
      27. Dsid_vorlauf(2) = &H66
      Display All
      und weiter unten dann die entsorechenden Subs (in neuem Beitrag ...)
      Was ich demnach schon weiß ist, daß ich die "mittleren 6 Bytes des Rom Codes umdrehen" muß, damit die Adressierung des einen abgefragten Sensors klappt. Weiter unten im Programm sieht es dann so aus:

      Source Code

      1. '********Hauptprogramm*************************************************
      2. Do
      3. If Stellen_taste = 0 Then Gosub Zeituebernahme 'wenn Taste Arduino D10 "rechts unten" gedrückt, dann String aus oben im Header vorgegebener Konstante einlesen (dafür muß die aber natürlich entsprechend vorbereitet, d.h. "frisch geschrieben" sein)
      4. Gosub Rtc_auslesen_und_anzeigen
      5. Waitms 1000 'hier kann und sollte natürlich im "Nutzprogramm" etwas anderes gemacht werden, bei mir z.B. alle 5s Temperaturen abfragen
      6. 'und auswerten. Dann entfällt dieses wait komplett
      8. '... hier anderer Code für S0 Leistungsanzeige
      10. Gosub 1wire_timen
      11. Gosub Tempauslesen
      12. Gosub Tempanzeigen
      14. Loop
      Display All

    • Source Code

      1. 1wire_timen: 'ich muss abwarten, bis der 1-Wire Bus "frei" ist, d.h. bis eine Lücke auftritt, die nach der Auslesung durch den Shelly Uni entsteht
      2. 'Fazit aus dem Log des LogicAnalyzers: die Auslesung der Temperatursensoren dauert ca. 550ms (ca. 490ms davon die Wandlungsphase ohne Zustandsänderung) und wird alle 5.000s wiederholt.
      3. 'Man hat also theoretisch 4.45s Zeit für neue Auslesungen oder andere Dinge. Wenn ich als "worst case" die Wandlungsphase und die Shelly-Auslesephase überspringe, dann bin ich "sicher" in
      4. 'der ca. 4.45s langen Phase bis zur nächsten durch den Shelly initiierten Wandlungsphase.
      6. For N = 1 To 250 'das dürfte dann ca. >=17ms dauern
      7. Do
      8. NOP
      9. Loop Until Portc.2 = 1 'C.2 ist Arduino A2/D16
      10. Waitus 65 'das scheint eine Periode im 1-Wire Bus zu sein
      11. Next N
      12. Waitms Wandlungszeit_ms 'nach dieser Wartezeit ist relativ sicher die Wandlungszeit überbrückt
      13. For N = 1 To 250 'das dürfte wiederum ca. >=17ms dauern
      14. Do
      15. NOP
      16. Loop Until Portc.2 = 1
      17. Waitus 65 'das scheint eine Periode im 1-Wire Bus zu sein
      18. Next N
      19. Waitms 60 'nach dieser weiteren Wartezeit ist auch sicher die Auslesezeit überbrückt
      20. 'wenn ich zu einem anderen Zeitpunkt in die Shelly-Sequenz eingestiegen sein sollte, schadet es auch nicht, denn die freie Zeit beträgt immerhin ca. 4.45s
      21. 'ich teste trotzdem noch einmal auf "Busfreieheit":
      22. For N = 1 To 5 'das dürfte weniger als 1ms dauern
      23. Do
      24. NOP
      25. Loop Until Portc.2 = 1 'C.2 ist Arduino A2/D16
      26. Waitus 65 'das scheint eine Periode im 1-Wire Bus zu sein
      27. Next N
      28. 'jetzt sollte der Bus frei für meine Abfrage sein
      29. Return
      30. '***********************************************************
      31. Tempauslesen:
      32. 1wreset
      33. 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      34. For I = 1 To 8
      35. 1wwrite Dsid_vorlauf(i)
      36. Next I
      37. 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      38. Rom_vorlauf = 1wread(2)
      39. Temp_vorlauf = Rom_vorlauf / 16 'so bekommt man auch Nachkommastellen!
      40. Return
      41. '***********************************************************
      42. Tempanzeigen:
      43. Lcdat 2 , 1 , "VL: " : Lcdat 2 , 19 , Temp_vorlauf : Lcdat 2 , 49 , " "
      44. 'Zeichen 1 geht von Pixel 1 bis 6, Zeichen 2 von 7 bis 12, Zeichen 3 von 13 bis 18 und Zeichen 4 von 19 bis 24... Zeichen "W" kann dann ab Pixel 37 bis Pixel 42 stehen.
      45. Return
      46. '***********************************************************
      Display All
      wie gesagt wird genau einmal die Temperatur des einen (von 4) von mir abgefragten Sensors korrekt ausgelesen und angezeit. Die ausgelesene Temperatur deckt sich exakt mit der, die mir auch der Shelly per Cloud anzeigt. Und daher weiß ich auch, daß ich richtig in der Annahme lag, daß der vom Shelly zuerst ausgelesene Sensor der für die Vorlauftemperatur ist.
      Aber warum stoppt mein Programm nach dieser einen Auslesung? Offenbar liegt es ja daran, daß die Bedingungen, die ich in der Sub "1wire_timen" einfordere, nicht noch ein zweites Mal erfüllt werden. aber warum nicht? Oder könnte es doch noch an etwas anderem liegen? Den Shelly beeindruckt meine "Parasitärauslesung" übrigens nicht. Er zeigt nach wie vor die Temperaturen an, sie wechseln auch hin und wieder (zumindest habe ich das bei einer anderen als der VL Temperatur beobachtet).

      Ich ändere den Code jetzt auch nochmal in Richtung Auslesung der anderen drei Sensoren. Ich würde erwarten, daß deren Auslesung auch mindestens 1x klappt und das Programm dann wieder hängen bleibt.

    • laase wrote:

      Loop Until Portc.2 = 1
      Erstaunlich das es überhaupt ging, das sollte 'Loop Until Pinc.2 = 1' heißen. Der Eingang (Pin) soll ja geprüft werden und nicht was Dein Code dem Ausgang (Port) mitgeteilt hat. ;)
      PS Warum nicht alle gleich nacheinander abfragen?

      laase wrote:

      ein Atmega48 wird mit der RTC aber überfordert sein
      Der Font braucht schon mehr als die Hälfte :(
      ca 200Byte und ein Haufen Arbeit (für den AVR) sparen folgende Änderungen:

      Source Code

      1. '********am Terminal (hier jetzt GLCD) anzeigen********
      2. Cls
      3. Lcdat 1 , 1 , "TT: " : Lcdat 1 , 30 , Ta1 'Tag ' nein, Lcdat kann nicht mehrere Strings hintereinander abbilden! Sie müssen EINZELN abgebildet werden, jeweils mit y und x Koordinaten. Das hier ging also nicht: Lcdat 1 , 1 , "TT:" , Tag
      4. Lcdat 2 , 1 , "MM: " : Lcdat 2 , 30 , Mo2 'nat
      5. Lcdat 3 , 1 , "JJ: " : Lcdat 3 , 30 , Ja3 'hr
      6. Lcdat 4 , 1 , "Stunde: " : Lcdat 4 , 72 , St4 'unden 'der x-Wert (i.S.v. Abstand zur Erstausgabe der Zeile) wird in PIXELN eingegeben, nicht in Stellen!
      7. Lcdat 5 , 1 , "Minute: " : Lcdat 5 , 72 , Mi5 'nuten
      8. Lcdat 6 , 1 , "Sekunde: " : Lcdat 6 , 72 , Se6 'kunden
      9. Lcdat 7 , 1 , "Wochentag: " : Lcdat 7 , 72 , Wo7 'chentag
      10. Lcdat 8 , 1 , "wird in RTC geschrieb" 'nur max 21 Zeichen über LCD darstellbar!!
      dann passt es auch in den 48 ;)

      The post was edited 2 times, last by Pluto25 ().

    • Pluto25 wrote:

      Warum nicht alle gleich nacheinander abfragen?
      das habe ich im Folgenden auch gemacht:

      Source Code

      1. '***********************************************************
      2. Tempauslesen:
      3. 1wreset
      4. 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      5. For I = 1 To 8
      6. 1wwrite Dsid_vorlauf(i)
      7. Next I
      8. 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      9. Rom_vorlauf = 1wread(2)
      10. Temp_vorlauf = Rom_vorlauf / 16 'so bekommt man auch Nachkommastellen!
      12. 1wreset
      13. 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      14. For I = 1 To 8
      15. 1wwrite Dsid_ruecklauf(i)
      16. Next I
      17. 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      18. Rom_ruecklauf = 1wread(2)
      19. Temp_ruecklauf = Rom_ruecklauf / 16
      21. 1wreset
      22. 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      23. For I = 1 To 8
      24. 1wwrite Dsid_aussentemp(i)
      25. Next I
      26. 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      27. Rom_aussentemp = 1wread(2)
      28. Temp_aussen = Rom_aussentemp / 16
      30. 1wreset
      31. 1wwrite &H55 'Befehl "Match ROM" (bestimmten Sensor adressieren/auswählen)
      32. For I = 1 To 8
      33. 1wwrite Dsid_lamellentemp(i)
      34. Next I
      35. 1wwrite &HBE 'Befehl "Read Scratchpad" (Speicher auslesen)
      36. Rom_lamellentemp = 1wread(2)
      37. Temp_lamellen = Rom_lamellentemp / 16
      38. Return
      39. '***********************************************************
      40. Tempanzeigen:
      41. Lcdat 2 , 1 , "VL: " : Lcdat 2 , 19 , Temp_vorlauf : Lcdat 2 , 49 , " "
      42. 'Zeichen 1 geht von Pixel 1 bis 6, Zeichen 2 von 7 bis 12, Zeichen 3 von 13 bis 18 und Zeichen 4 von 19 bis 24...
      43. Lcdat 2 , 51 , "RL: " : Lcdat 2 , 69 , Temp_ruecklauf : Lcdat 2 , 99 , " "
      44. Lcdat 3 , 1 , "AT: " : Lcdat 3 , 19 , Temp_aussen : Lcdat 3 , 49 , " "
      45. Lcdat 3 , 51 , "La: " : Lcdat 3 , 69 , Temp_lamellen : Lcdat 3 , 99 , " "
      46. Return
      47. '***********************************************************
      Display All
      es hat wieder auf Anhieb geklappt, ich sehe jetzt die 4 Temperaturen auf meinem Display. Aber leider nur 1x .... :( Aber immerhin bin ich schon nahe dran, denke ich ...


      Pluto25 wrote:

      Erstaunlich das es überhaupt ging, das sollte 'Loop Until Pinc.2 = 1' heißen. Der Eingang (Pin) soll ja geprüft werden und nicht was Dein Code dem Ausgang (Port) mitgeteilt hat.
      Uuups, ja, das ist ein guter Hinweis! Das ändere ich mal gleich noch. Mal sehen, ob es sich danach genauso verhält, bin gespannt!

    • @Pluto25: vielen Dank! Das war's! Der Code läuft jetzt durch und die Temperaturen werden sauber ausgelesen. Bedingt durch die kurze Wartezeit werden sie innerhalb der 4,45s "Freizeit" sogar 2-3 x ausgelesen, aber das kann ich ja über die Wartezeit(konstanten) und die Länge anderen auszuführenden Codes noch bequem ändern. Vielleicht belasse ich es auch besser bei einer Abfrage alle 5s, kurz nach der Abfrage durch den Shelly, weil ich hörte, daß allzu häufige Abfragen die Sensoren innerlich erwärmen und dann ungenaue Messergebnisse herauskommen.

      Ich hänge den jetzigen Codestand an, falls das irgendwann mal jemand interessieren sollte. Er soll noch weiter entwickelt werden in Richtung schalten verschiedener Zustände der Wärmepumpe, der Ölheizung, der ÖH-Umwälzpumpe und des Ventils für die Warmwasser-Nachheizung in Abhängigkeit von Temperaturen, Zeiten, Historie des vergangenen Tages usw., aber das sind dann relativ einfache Sachen, die außerdem wohl bei jedem Nachnutzer anders sein werden.
      Im Code ist auch noch die Auslesung einer S0 Schnittstelle mit drin, die für meine Zwecke (Anzeigebereich 1 bis ca. 6000W des S0 Ausgangs eines Drehstromzählers mit 800 Impulsen je kWh) auch funktioniert, aber noch nicht bis ins Detail geprüft wurde. Überhaupt steht noch zeimlich viel Kommentar drin, der aber vll auch nicht schlecht ist, um meine Gedankengänge nachvollziehen zu können.
      Files

    • laase wrote:

      daß allzu häufige Abfragen die Sensoren innerlich erwärmen
      Das kann ich hier nicht bestätigen, ist aber sicher nicht ausgeschlossen.
      Jedoch kann Dein Code zu Kollisionen führen. Die 1wire_timen prüft nicht ob C.2 mal Low war. Daher könnte sie die Freigabe nach 4,9 Sekunden geben und damit "Crash"
      Dann "verbraucht" sie fast eine Sekunde in der der Code nichts tun kann a_481_60a3be70
      Ich würde den Pcint1 vorschlagen.
      Der könnte eine '1wfrei' Variable rücksetzen und sich selber abschalten (damit er nicht hunderte Male aufgerufen wird)
      Die Isr_timer1 kann dann die '1wfrei' incrementieren
      Damit ist der 1wire immer frei wenn '1wfrei' 2 und 3 ist

    • Hallo Pluto,
      ja, Du hattest recht, führte zu Kollisionen. Mindestens zu einer jedenfalls, denn gestern gegen 10 Uhr registrierte der Shelly einmal eine Temperatur von "-211.38°C" auf dem letzt-ausgelesenen Sensor (Lamellentemperatur). So etwas möchte man natürlich überhaupt nicht, weil es mindestens die ganzen Auswertungsmöglichkeiten "tiefste Temperatur des Tages/Woche/Monats/Jahres" usw. komplett durcheinander bringt und nutzlos macht. Man kann ja leider keinen Wert, der einmal in der Shelly Cloud gespeichert wurde wieder löschen oder ändern.
      Aber natürlich ist es auch für die von meiner Heizungssteuerung ausgelesenen (und weiter verwendeten) Werte doof, wenn die Temperatur auf einmal in einen Bereich springt, der zB eine bestimmte Schaltroutine auslöst. Kurz gesagt: ich mußte was machen. Ich habe dann also am Timing (Synchronisation/Abstimmung mit dem Shelly) gearbeitet und zusätzlich noch einen Filter implementiert, der ein "Fenster zulässiger Werte" und eine maximal zulässige Steigerung bzw. Fall des jeweiligen Sensorwerts berücksichtigt.
      Sorry, ich hatte das schon vor und während Du Deinen Vorschlag mit dem PCINT1 gepostet hattest bearbeitet. Daher habe ich jetzt eine Lösung ohne Interrupt drin, also "reines Polling": (Sub 1wire_timen am Anfang ergänzt)
      For N = 1 To 3
      Do
      NOP
      Loop Until Pinc.2 = 0 'der Bus soll hier ein paarmal L sein (aktiv sein)
      Waitus 65
      Next N

      Das klappt und läuft seither stabil. Ich verursache seither keine Kollisionen mehr. Zusammen mit dem neu eingefügten Filter (Sub Temperaturpruefung) habe ich auch "stabile" Messungen (siehe angehängte neue Datei). Der Code ist jetzt allerdings auf 10,9k (33%) angewachsen.
      Ein Manko gibt es aber immer noch: Falschauslesungen, die zum Temperaturwert "-0.0625°C" (ist das der Binärwert 1111 1111 1111 1111 ?) führen. Die muß ich auch noch herausfiltern. ZB indem ich mir immer dann eine Warnflag setze, wenn eine der ROM-Variablen beim Auslesen diesen Binärwert annimmt. Habe ich im Code aber noch nicht umgesetzt.
      Ich stelle fest: ich stehe dort, wo ich bei vorherigen Projekten auch schon oft stand: die selbst ausgelesenen Temperaturwerte sind durch Störungen (>12m Leitungslänge und benachbarte Netzkabel mit höherem Störanteil) tendenziell unzuverlässig und müssen nachträglich bewertet werden, bevor ich sie als zuverlässig übernehme. Ich tippe, daß selbst dann wenn ich alle Bytes der Sensoren auslese und eine CRC Prüfung mache (zZt lese ich ja nur die zwei Temperaturbytes aus, ich sicherheitshalber immer noch den Filter durchlaufen sollte.
      Files