Viele Solaranlagen verwenden den universellen Regler UVR1611 (inklusive
Zubehör) von
Technische Alternative GmbH
Internet: http://www.ta.co.at
Auch der Braunschweiger Solaranlagenhersteller SOLVIS verwendet diese
Komponenten (zumindest bei mir).
Der Regler besitzt eine zweipolige Datenleitung DL, auf der zyklisch
etwa 1/s alle wichtigen internen Analog-und Digitalwerte ausgegeben
werden.
Mit einer zweiadrigen Leitung kann das Signal zu einer entfernten Stelle
weitergeleitet und dann dekodiert angezeigt werden.
Durch den großen Pegelhub und den relativ langsamen Signalwechseln ist
das Signal recht störunempfindlich.
Die Dekodierung kann recht einfach mit einem AVR durchgeführt werden.
Die SW soll mehr ein Beispiel dafür sein, wie die Signale dekodiert und
angezeigt werden können. Wegen der recht unterschiedlichen
Einsatzmöglichkeiten des Reglers, sind Änderungen und Anpassungen
notwendig.
Harald
Hallo Harald, habe mich nun mal daran gemacht deinen Code zu verstehen,
da ich allerdings noch nicht ganz so fit in C bin kam ich recht schnell
ins Straucheln...
Deshalb hier ein Paar fragen:
Welche verwendung hat der EEProm in deiner Programmierung?
Sehe ich dass richtig dass du das Signal mit UART auswertest, weil du
diese initialisiert hast? Aber das Protokoll des UVR ist doch etwas
anderst aufgebaut?!
Vielleicht schaff ich es ja deinen Code etwas mehr zu verstehen wenn du
mir die Fragen beantwortest.
Danke schonmal
Gruß
Jochen
Das DL-Signal wird nur an PD2 (=INT0) geführt und dann per Interrupt
ausgewertet. Der UART wird bei mir nur für Testzwecke benutzt. Man
braucht ihn also eigentlich nicht.
Zum Einlesen benötigt man nur die ISR-Routinen (ohne UART) und die
DL-Struktur mit ein paar Hilfsbytes.
Die Sprache C ist eigentlich auch nicht mein Favorit (vgl.
http://www.henning-thielemann.de/CHater.html), aber die einzige
vernünftige Alternative dazu (beim AVR) wäre Assembler. Für einfache
uP-Aufgaben kann man jedoch auch mit C arbeiten. Immerhin gibt es viele
Tutorials im Netz. Zumindest halte ich ein C-Programm für verständlicher
als ein ASM-Programm.
Wenn es helfen sollte, könnte ich das Programm mal so abspecken, daß nur
die Auswerteroutinen übrig bleiben. Was man dann mit den empfangenen
Daten macht, bleibt jedem selbst überlassen.
Harald
Harald P. wrote:
> Wenn es helfen sollte, könnte ich das Programm mal so abspecken, daß nur> die Auswerteroutinen übrig bleiben. Was man dann mit den empfangenen> Daten macht, bleibt jedem selbst überlassen.
Dafür wäre ich dir echt dankbar, dann könnte ich es mit einer
UART-Routine verknüpfen, dass dürfte ich mit meinen jetzigen
C-kenntnissen noch schaffen.
Gruß
Ich habe auch eine UVR1611 und interessieren sich für das Projekt
haraldp
haraldp oder kann jemand schicken Sie das Muster, um es zu machen?
Vielen Dank an alle
sorry aber ich benutze die automatischen Übersetzer zu schreiben.
wenn möglich, ich brauche Schema elektronischen Leiterplatten und Ihrer
avr88 Board mit LCD zu mir selbst zu bauen.
Dank
Hallo Holger,
ich war im Urlaub, so daß ich erst jetzt mir die Forenbeiträge
angeschaut habe. Die Frage habe ich nicht verstanden. Welche Sensorwerte
solllten in den Bus dazugepackt werden und von wem?
So wie ich das verstanden habe, kann man die Zuordnung der Signale auf
den DL-Bus nicht ändern. Aber vielleicht doch. Vielleicht weiß da jemand
mehr.
Harald
Hi Allerseits,
un hoffe einen guten Urlaub gehabt zu haben :)
Das Thema ist spannend und ich auf einem ähnlichem Weg.
Das Auslesen des DL mit nem AVR ist schon eine nette Lösung.
Zum Schreiben auf dem DL hab ich noch nichts gefunden, bin aber am
sammeln inwiefern über den CAN-Bus direkt das umsetzbar wird.
Als Verarbeiter dann ein AVR und CAN-Transceiver und dann sollte es
gehen.
Den vorhandenen UVR spielt man vor, man sei ein oder mehrere I/O-Module
und baut sie entsprechend auch in seiner Regelung ein.
Ich werde wohl nicht den AVR nehmen sondern direkt einen Kleinstrechner
(Beaglebone), so kann ich gleich den Home-Automation-Server mit
Webinterface mitlaufen lassen. Falls mir das mißlingt, wirds AVR und nen
UART. (ist auch günstiger).
Aber noch ist nichts am laufen, daher bin ich gespannt auf Ideen.
Habt ihr eine Protokollbeschreibung für den CAN-Bus von TA bekommen?
Besten Gruß
Bene
Ja, über CAN kann man auch auf die UVR1611 zugreifen. Das habe ich auch
getestet, dann aber wieder aufgegeben.
Testaufbau:
- CAN Transceiver MCP2551
- 2 schnelle Optokoppler zur Entkopplung Rx,Tx (könnte auch entfallen)
- CAN Controller MCP2515
- ATMega88
dazu ein Terminalprogramm, das den CAN-Controller bedient.
Grundsätzlich hat es funktioniert. Variable etc. ließen sich auslesen.
Setzen haben ich nicht probiert. Insgesamt bin ich mit dem CAN-Bus
schlecht klargekommen.
TA hat mir zwar 2 Dokumente dazu geschickt, aber ohne tiefe
CAN-Kenntnisse kann man wohl nicht allzuviel damit anfangen. CSDO, SSDO
usw. blieben mehr oder weniger böhmische Dörfer für mich.
Durch allzu rigides Auslesen von CAN-Nachrichten habe ich die UVR zum
Absturz gebracht. Aber glücklicherweise war alles reversibel.
Also, kein echter Erfolg. Mir reicht der DL-Bus.
Harald
Hallo Harald,
... TA hat mir zwar 2 Dokumente dazu geschickt, aber ohne tiefe
CAN-Kenntnisse kann man wohl nicht allzuviel damit anfangen...
Kannst du diese 2 Dokumente bitte mal zur Verfügung stellen ?
Bin auch an diesem Thema interessiert.
Gruß Jo
Hallo allerseits,
ein Super Beitrag das Auslesen über DL-Bus.
Bei mir steht die Aufgabe einen Festbrennstoff-Kessel über einen MODBUS
anzubinden. Als MODBUS wird RS-485 als physische Schnittstelle
verwendet. Nun benötige ich ein Gateway von MOD-Bus zu CAN-BUS oder von
MOD-BUS zu DL.
Hat jemand soetwas schon gemacht?
Viele Grüße
Karsten
meinolf lutter schrieb:> hallo> habt ihr euch schonmal gedanken demacht den DL-Bus an einen Raspberry zu> bringen ?
Könnte evtl. funktionieren, da die Signalwechsel nicht allzu häufig
sind. Besser ist jedoch eine Art Gateway mit AVR. So habe ich das
gemacht:
HW: AtMega16; ENC28j60
SW: gesagtes DL-Pgm; DL-Daten werden per Udp-Broadcast gesendet.
Jeder Ethernet-Teilnehmer (auch RPi) kann dann diese Daten empfangen und
auswerten.
Harald
Hallo Harald,
das was Du da gemacht hast ist ziemlich genau das, was ich auch suche.
Ich hab' den NET-IO von Pollin und versuche dem genau das beizubringen.
Ich denke Dein Ansatz wäre ein Interessantes Projekt hier. Meinst Du, Du
könntest da was zur Verfügung stellen?
Gruß,
Olli
Olli schrieb:> Ich denke Dein Ansatz wäre ein Interessantes Projekt hier. Meinst Du, Du> könntest da was zur Verfügung stellen?>> Gruß,> Olli
Na ja, in meinem Programm stecken noch viele weitere Details:
- Mittelwertbildung
- Gaszählerauslesung
- Rolladensteuerung
- (ungenutzte) SD-Kartenansteuerung
- zusätzliche RS485-Schnittstelle
- ...
Mit dem kompletten Programm könnte keiner außer mir etwas anfangen. Die
SW-Bausteine für das oben genannte Ziel sind doch eigentlich alle da:
- DL-Bus auslesen
- 64Byte Daten zusammenstellen
- per Udp senden
Harald
Ich habe ein einfacheres Model von TA, die UVR-31, die bei mir seit 1996
läuft und den gleichen Bus verwendet erfolgreich an den Raspberry B+
angebunden (PIGPIO Bibliothek für den GPIO Zugriff mit Python). Die
CPU-Last am Raspberry liegt für den PIGPIOD Daemon und das Python
Programm bei ca. 10-15%. Das Protokoll nutzt den Manchester Code. Daher
wird auch die UVR-1611 problemlos funktionieren.
Die Pegelanpassung erfolgt mittels einiger weniger Komponenten (ein
CNY17 Optokoppler mit Diodenschutzschaltung und zwei Widerstände),
Kosten weniger als 1€ (Siehe beiliegende Simulation der Schaltung mit
LTSpice IV).
Das Ganze kostet deutlich weniger als D-LOGG (aber viel mehr Zeit ;-) ).
skg
hallo harald,
hast du von deiner anzeige ein schaltplan oder platinenlayout ?
habe versucht das dl signal mit dem arduino zu dekodieren.
klappt nur sporadisch. ich nehme an das der avr durch das arduino
zu stark ausgebremst wird.
meinolf ( dl6dbh)
meilu schrieb:> hast du von deiner anzeige ein schaltplan oder platinenlayout ?
Es gibt bei nur Lochrasterplatinen mit Fädeldraht (0.2mm CuL aus alten
Trafos). Ein - zugegebenermaßen - rudimentären Schaltplan findest du in
der Anlage
Harald P. schrieb:> Autor:>> Datum: 03.08.2010 17:29
Viel ist da nicht zu verschalten: Ein Eingang am AVR für das DL und 6
Ausgänge für ein LCD. Das Ganze habe ich inzwischen 4x realisiert in
unterschiedlichen Umgebungen. Kritisch ist da nichts. Auch ein
vorgeschaltetet Optokoppler darf durchaus CNY17 o.ä. sein.
Harald
Hallo,
könnt Ihr mir das Layout für das Auslesen einer ESR zukommen lassen?
Können die Daten auch in FHEM übernommen werden?
Hintergeund ist, dass ich über einen RPI und FHEM die Heizungsdaten
aufnehme, aber leider die Daten der Solaranlage nicht einlesen kann, da
das eine ESR31 von TA ist.
Mein Plan wäre noch, die Heizung automatisch abzuschalten, wenn Wärme
von Solar anliegt.
Gruß
Jens
Robert Walli schrieb:> Welche Änderungen müsste ich an der abgespeckten Version vornehmen damit> sie auf einem atmega328 läuft?
Gar keine, Mega328 hat (fast) diesselbe Architektur wie der Mega88.
Gerade ausprobiert: Programm kompiliert mit M328p als Target.
Ergänzen mußt du, was du mit den eingelesenen DL-Daten machst. Aber das
dürfte dir wohl klar sein.
Harald
Hallo Harald,
Danke für Deine Antwort!
Ich probier das ganze gerade zum Laufen zu bringen und
versuche mir grad das Wissen dazu anzueignen.
Ich habe bislang die timer nur mit den Arduino-Libraries konfiguriert
und tu mich ziemlich schwer ohne diese:(
Ich hab den praescaler für timer0 auf 1024 umgestellt und die OCR0A's
angepasst aber leider ohne Erfolg.
Die 16 Syncbits werden Erkannt, dann aber passt was mit den timings
nicht.
Hab ich da was falsch verstanden?
Du schreibst ja dass Du den atmega88 mit 8MHz betreibst.
Mein 328 läuft ja mit 16Mhz, da passen ja die ganzen Timings nicht...
Robert
Robert Walli schrieb im Beitrag
>> Hab ich da was falsch verstanden?> Du schreibst ja dass Du den atmega88 mit 8MHz betreibst.> Mein 328 läuft ja mit 16Mhz, da passen ja die ganzen Timings nicht...>> Robert
Umrechnen der Timerwerte ist natürlich notwendig. Anhand der
Datenblätter dürfte das recht einfach sein.
Harald P. schrieb:> Umrechnen der Timerwerte ist natürlich notwendig. Anhand der> Datenblätter dürfte das recht einfach sein.
Hab ich da einen Denkfehler?
Der 328 läuft doppelt so schnell, somit hab ich den Timer2 gleich
gelassen und OCR2A von 78 auf 156 gestellt.
Der Timer0 würde bei 255 überlaufen, daher hab ich ihn von 1:256 auf
1:1024 gestellt:
(TCCR2B = (1 << CS22) | (1 << CS21) | (1 << CS20)).
Anschliessend habe ich alle OCR0A halbiert und "TCNT0 > 80" auf "TCNT0 >
40" gestellt.
(Timer0 ist mit 1/4 der Geschwindigkeit konfiguriert und der 328er
taktet doppelt so schnell -> timer0 läuft mit der 1/2 Geschwindigkeit).
Ich bekommen dann als ersten Byte immer 0x30 (es sollten 0x90 sein).
Die Restlichen hab ich nicht kontrolliert.
Hab ich da irgendwas vergessen?
Robert
Robert Walli schrieb:> Hab ich da einen Denkfehler?> Der 328 läuft doppelt so schnell, somit hab ich den Timer2 gleich> gelassen und OCR2A von 78 auf 156 gestellt.
Ja, Denkfehler.
Wenn der m328 doppelt so schnell läuft, dann verdoppeln sich auch die
Zählerwerte.
Für die Dekodierung von DL braucht man hier nur den Timer0. Also bei
16MHz gilt:
1
if(TCNT0>160||TIFR0)// 2048us
2
dann2x
3
OCR0A=95;// 1536us
4
unddann
5
OCR0A=127;// 2048us, für Bits1..8 wirksam
Die Werte habe ich hier korrigiert, da ich ursprünglich vergessen hatte,
daß die resultierende Frequenz bei CTC (f/OCR0A+1) ist. Aber so kritisch
ist das Ganze nicht.
Den Timer2 verwende ich nur zur Ausfalloffenbarung. Wenn länger als 5s
keine gültige Daten kommen, gilt das als Ausfall. Da gibt es 1000
weitere Methoden das zu machen.
Die Initialisierung von Timer0 kann so bleiben, also Vorteiler 1:256.
Harald
Hallo Harald,
Danke nochmals für deine Hilfe!
Harald P. schrieb:> Wenn der m328 doppelt so schnell läuft, dann verdoppeln sich auch die> Zählerwerte.
Ja schon, aber ich habe - wie im vorigen post geschrieben - den
prescaler auf 1:1024 gestellt, da der 8Bit Timer ja nicht bist 512
kommt.
Dh. der Timer müsste 1/2 so schnell laufen, oder?
Ich glaube da ist wo anders der Wurm drinnen.
Ich hab mal länger (500 - 1000) Zyklen gewartet und dann ist folgendes
gekommen:
11111111111111111110111111101001
11111111111111111110111100110000
11111111111111111110111101010110
11111111111111111110111101000000
11111111111111111110111101101110
11111111111111111110100010000000
anschliessend wieder 100 Zyklen nichts und dann wieder ein Wert.
Ich hab in Deinem Code beim "// mach was mit den Daten" für 6 Werte
(i=0-6):
Serial.println(DLWerte.t.Temp[i],BIN);
geschrieben.
Warum kommen da 32-Bit?
Ich bin ratlos:(
Robert
Hallo Harald,
Danke für deine Geduld.
Hier mal der Code und Schaltplan.
Ich hab jetzt Deinen Orginalcode hergenommen und nur die 3
Timer-änderungen von Deinem Post angepasst.
Ich hab den UVR-61-3, hab aber den 65Byte-Datensatz vorerst drinnen
gelassen.
Zum Testen müsste es reichen.
Jedoch ändert das auch nichts:
Ich bekommen jedoch immer den output wie im Anhang:
0x90 0x48 0xAA...
Richtig wäere:
0x90 0x6F 0xAA...
Mir fehlen die Ideen.
Robert
PS: Einen Screenshot eines Logic Analyzer hab ich auch noch angehängt...
Was mir sofort auffällt, ist, daß das DL-Signal bei dir nichtinvertiert
ankommt. Bei mir sitzt noch ein Optokoppler dazwischen,der für eine
Invertierung sorgt.
Hallo Harald!
Ich könnte mir in den A. beissen.
Ich habe einen Optokoppler gefunden und das ausprobiert:
Funktionierte auf Anhieb!
Das Gute an der Sache: ich habe viel über Timer gelernt und ich habe
auch den Timingfehler im Logic Analyzer gefunden. (Stolz)
Nur leider die Ursache nicht ;)
Danke nochmals!
Robert
Hallo,
Ich möchte den Volumenstromsensor HUBA FTS4-50DL von
Technische Alternative GmbH
mit einem ATMEGA auslesen. Weiß jemand, wie der Befehl auszusehen
hat, um diesen Sensor auszulesen?
Gruß
Wolfram
schwedenfan schrieb:> Hallo,>> Ich möchte den Volumenstromsensor HUBA FTS4-50DL von> Technische Alternative GmbH> mit einem ATMEGA auslesen. Weiß jemand, wie der Befehl auszusehen> hat, um diesen Sensor auszulesen?>> Gruß> Wolfram
get FTS4-50DL(int Durchfluss);
hallo
ich habe ein arduino -> canbus-shield
im terminal kann ich jetzt daten des canbus mitlesen
kann die werte aber nicht reproduzieren.
hat sich da schonmal einer versucht ?
gruß mmeilu
Hallo zusammen,
ähnliches Thema aber UVR64 als Steuerung.
Ich möchte die Daten von der Datenleitung (DL) gerne mittels ESP8266 an
meine Heimautomatisierung weiterleiten (ioBroker) und dort
visualisieren.
Kann mir bitte jemand helfen und sagen wie die Verkabelung zwischen
DL-Leitung und ESP sein muss?
Wie bekomme ich die Daten dann weiter? Auf meinem ESP8266 läuft ESPEasy.
Danke Ingo
Das DL-Signal der UVR64 müßte sich auch mit meinem Programm dekodieren
lassen. Allerdings ist die Nachricht kürzer, siehe
Schnittstellenbeschreibung in der ursprünglichen zip-Datei.
Ob der ESP8266 das kann, weiß ich nicht; vermutlich geht es. ESPEasy
kenne ich nicht, wahrscheinlich wird es erst mit einer Erweiterung
funktionieren. Das Problem beim ESP ist, daß er im Hintergrund die
WLAN-Funktionen bearbeitet, so daß evtl. nicht sichergestellt ist, ob
die Timing-Bedingungen eingehalten werden können.
Ich würde einen ATMEGA spendieren, der als Grundgerüst mein Programm
enthält, und dann die empfangenen UVR-Daten seriell an einen ESP
ausgeben und von dort aus weiter über WLAN. Oder ein ENC28J60-Modul an
den ATMEGA anschließen und dann die Information als UDP an das Netzwerk
übergeben. Die Erweiterung zur Ansteuerung des ENC ist relativ einfach.
Beispiele hierfür findet man hier im Forum.
Harald
Hallo Harald,
vielen Dank für deine prompte Antwort.
Ich würde es im ersten Schritt mal mit einem ESP8266 versuchen.
Muss ich bei der Verkabelung etwas beachten?
Oder einfach die DL Leitung an einen Pin (welchen?) am ESP?
Oder müssen irgendwelche Wiederstände dazwischen weil in der
Schnittstellenbeschreibung steht, das die Ausgangsschaltung der
Datenleitung 24V beträgt?
Wäre schön wenn du mir nochmal helfen würdest.
Herzlichen Dank, und viele Grüße,
Ingo
Hallo Ingo,
Das DL Signal wird bei mir über einen Optokoppler (SFH610, Vorwiderstand
6.8K vor LED, Kollektor an PORTD2, Emitter an Masse) an INT0 geführt.
Welcher ESP-Eingang interruptgesteuert werden kann, weiß ich nicht. Wie
willst du den ESP programmieren? Als Arduino (wäre wohl am einfachsten,
aber funktioniert evtl. nicht wegen Timing) oder mit dem SDK?
Da die Zeiten relativ lang sind, könnte möglicherweise auch ein Polling
funktionieren. Das müßtest du selbst programmieren.
Harald
Hallo Harald,
hättest du evtl. eine kleine Skizze zwecks Aufbau und Verkabelung für
mich?
Ich bin da nicht ganz so firm.
Zwecks Datentransport sehe ich kein Problem, das erledigt ESPEasy (die
Firmware auf dem ESP) für mich. Die Daten selbst kann ich dann mit einem
Script im ioBroker auseinandernehmen.
Mir geht es primär um den Aufbau bzw. Zusammenschluss der Komponenten
inkl. Widerständen etc. Da kenne ich mich leider nicht ganz so gut aus.
Grüße Ingo
Hallo,
wie würde man vorgehen, wenn man eigene Temperaturwerte auf den Bus
schreiben will? Ich würde hier gerne einen AVR als DS18B20/DL Bus
Gateway nutzen und den DL Bus Koppler/Sensoreingang emulieren (um
möglichst viele Werte übergeben zu können, das wären 24 bei dem). Darf
man einfach so auf den Bus schreiben oder gibt es einen master der das
ganze aufteilt? Wie sieht's mit Kollisionserkennung aus? Hat irgendwer
da schon mal eine Schaltung für getestet?
Liebe Grüße
Hallo,
ich bin so eben sehr erfreut auf den Tread gestorben zu sein.
Ich besitze eine Solarfous UVR42 Solarsteuerung welche eine Datenleitung
zum Ausgeben der Temperaturwerte hat.
https://www.ta.co.at/fileadmin/Downloads/Betriebsanleitungen/00_Altgeraete/uvr42e2_4.pdf
Mittels Multimeter konnte ich eine Pegel von 9-19V AC messen.
Hierbei wird eine UVS 232 (es sollte auch D-LOGG gehen) benötigt.
Meine Überlegung war, die Temperaturwerte der Solaranlage über die
Datenleitung auszulesen und diese mittels eines ESP8266 über MQTT an
mein Openhab zu senden.
Gibt es hierfür schon Erfahrung bzw könnte mir jemand dabei helfen.
Die Schaltung mittels Optokoppler konnte ich schon den Beiträgen
entnehmen. Muss diese dann an den RX Pin angeschlossen werden, oder darf
hier jede beliebige Datenleitung genutzt werden?
Wenn das funktionieren würde wäre das MEGA :)
Ingo K. schrieb:> Hallo Harald,>> hättest du evtl. eine kleine Skizze zwecks Aufbau und Verkabelung für> mich?> Ich bin da nicht ganz so firm.>> Zwecks Datentransport sehe ich kein Problem, das erledigt ESPEasy (die> Firmware auf dem ESP) für mich. Die Daten selbst kann ich dann mit einem> Script im ioBroker auseinandernehmen.>> Mir geht es primär um den Aufbau bzw. Zusammenschluss der Komponenten> inkl. Widerständen etc. Da kenne ich mich leider nicht ganz so gut aus.>> Grüße Ingo
Hallo,
hat die Kommunikation und das Auswerten der Temperaturwerte mittels
ESP8266 funktioniert?
Schau dir das mal an.
https://github.com/martinkropf/UVR31_RF24
ich habe mir das vor 4 Jahren für meinen UVR64 umgebaut und die Daten
dann via RS232 an einen Raspi weitergeleitet. Auf dem Raspi habe ich
dann zwei Programme die diese Daten auf den MQTT Broker, welche auch auf
dem Raspi läuft, weitergeben. Ist mehr ein Hack, aber läuft jetzt schon
ein paar Jahre.
Das Arduino Programm von Martin Kropf kannst du ja auf den 8266 portiern
und um die MQTT Funktion/Ausgabe erweitern.
Zur Frage mit dem Optokoppler, den hängt du auf einen "normalen"
Eingang, denn das TA-Protokoll hat mit einer RS232 Kommunikations nichts
zu tun.
Uli S. schrieb:> Schau dir das mal an.> https://github.com/martinkropf/UVR31_RF24>> ich habe mir das vor 4 Jahren für meinen UVR64 umgebaut und die Daten> dann via RS232 an einen Raspi weitergeleitet. Auf dem Raspi habe ich> dann zwei Programme die diese Daten auf den MQTT Broker, welche auch auf> dem Raspi läuft, weitergeben. Ist mehr ein Hack, aber läuft jetzt schon> ein paar Jahre.>> Das Arduino Programm von Martin Kropf kannst du ja auf den 8266 portiern> und um die MQTT Funktion/Ausgabe erweitern.> Zur Frage mit dem Optokoppler, den hängt du auf einen "normalen"> Eingang, denn das TA-Protokoll hat mit einer RS232 Kommunikations nichts> zu tun.
Wow, vielen Dank.
Du hast also, wie von "S. K." gepostet, eine Optokoppler für die
Kommunikation genutzt und diesen an den RX Port des RPI angeschlossen?
Ich hätte einen PC817 herumliegen, könnte ich den auch nutzen?
Auf dem RPI läuft somit dein python Skript welches die Daten an den MQTT
Broker schickt?
https://github.com/martinkropf/UVR31_RF24/blob/master/Receiver/recv.py
Falls es doch nicht das im Link befindliche Python Skript handelt würde
ich dich um deine genutzten Programme bitten.
Super, ich werde versuchen die Files im Ordner "UVR31_RF24" auf meinen
ESP8266 zu laden.
Ich habe einen Arduino Nano zwischengeschalten. Dieser nimmt die Daten
über einen SFH618A auf. Dein PC817 sollte auch passen.
Ich verwende ein, ein wenig modifiziertes ino Porgramm (also C) auf dem
Arduino. Dieses sendet die empfangenen Daten dann über den RS232/USB
Anschluss des Arduino Nanos an den Raspi (UBS-Anschluss).
Das kann man eleganter mit dem 8266 machen und über WLAN direkt an den
MQTT-Raspi weitersenden.
Vielleicht mache ich das einmal, wenn ich Lust und Zeit habe. Aber dann
muss ich auch den Keller mit WLAN ausrüsten
ich habe diesen Teil als Ausgangsbasis verwendet
https://github.com/martinkropf/UVR31_RF24/tree/master/UVR31_RF24
Uli S. schrieb:> Ich habe einen Arduino Nano zwischengeschalten. Dieser nimmt die Daten> über einen SFH618A auf. Dein PC817 sollte auch passen.> Ich verwende ein, ein wenig modifiziertes ino Porgramm (also C) auf dem> Arduino. Dieses sendet die empfangenen Daten dann über den RS232/USB> Anschluss des Arduino Nanos an den Raspi (UBS-Anschluss).>> Das kann man eleganter mit dem 8266 machen und über WLAN direkt an den> MQTT-Raspi weitersenden.> Vielleicht mache ich das einmal, wenn ich Lust und Zeit habe. Aber dann> muss ich auch den Keller mit WLAN ausrüsten>> ich habe diesen Teil als Ausgangsbasis verwendet> https://github.com/martinkropf/UVR31_RF24/tree/master/UVR31_RF24
Deine Lösung klingt sehr spannend.
Nachdem mein RPI2 nicht in der nähe des Kellers ist würde ich es über
WLAN und MQTT nutzen.
Leider bin ich kein Experte im Programmieren und bräuchte eine Kleien
Hilfe.
Ich habe das Main File schon angepasst für die MQTT Kommunikation:
1
/*
2
~~~~~~~~~~
3
UVR31_RF24
4
~~~~~~~~~~
5
Martin Kropf 2015
6
7
UVR31_RF24.ino:
8
Phase change between receiving and processing
9
10
*/
11
12
13
// If DEBUG is defined all dump commands (dump.h/dump.ino) are compiled and
14
// output occurs via Serial. If DEBUG is commented out, the web upload
15
// (web.h/web.ino) is compiled and used instead. Both at once doesn't work
16
// (on the Leonardo) because the RAM storage is too small.
17
18
//#define DEBUG
19
20
// if USINGPC is defined, output is displayed on the Serial Monitor.
21
// Should be turned on if the Arduino is used on the PC,
22
// as soon as it is used with own power supply, you should comment it out.
23
24
//#define USINGPC
25
26
// adjust these values to your needs, for that remove the comments /* */ (the values in the comments are examples)
27
28
#define MQTTDEF
29
30
constbytedataPin=2;// pin with data stream
31
// interrupt for data pin, see:
32
// http://arduino.cc/en/Reference/AttachInterrupt
33
constbyteinterrupt=0;
34
35
//---------MQTT Test------
36
#include<ESP8266WiFi.h>
37
#include<PubSubClient.h>
38
39
constchar*SSID="xxxxxxxx";
40
constchar*PSK="xxxxxxxx";
41
constchar*MQTT_BROKER="192.168.2.108";
42
43
WiFiClientespClient;
44
PubSubClientclient(espClient);
45
46
47
48
// ======================
49
50
#include<SPI.h>
51
52
#include"receive.h"
53
#include"process.h"
54
#include"dump.h"
55
#include"NRF24.h"
56
57
voidsetup(){
58
#ifdef USINGPC
59
Serial.begin(115200);
60
#endif
61
// in DEBUG mode output via serial, otherwise web upload (see above)
62
#ifdef DEBUG
63
Serial.println("Press key for detailed output.");
64
#else
65
NRF24::start();
66
#endif
67
Receive::start();
68
69
#ifdef MQTTDEF
70
Serial.begin(115200);
71
setup_wifi();
72
client.setServer(MQTT_BROKER,1883);
73
#endif
74
}
75
76
voidsetup_wifi(){
77
delay(10);
78
Serial.println();
79
Serial.print("Connecting to ");
80
Serial.println(SSID);
81
82
WiFi.begin(SSID,PSK);
83
84
while(WiFi.status()!=WL_CONNECTED){
85
delay(500);
86
Serial.print(".");
87
}
88
89
Serial.println("");
90
Serial.println("WiFi connected");
91
Serial.println("IP address: ");
92
Serial.println(WiFi.localIP());
93
}
94
95
voidreconnect(){
96
while(!client.connected()){
97
Serial.print("Reconnecting...");
98
if(!client.connect("ESP8266Client")){
99
Serial.print("failed, rc=");
100
Serial.print(client.state());
101
Serial.println(" retrying in 5 seconds");
102
delay(5000);
103
}
104
}
105
}
106
107
voidloop(){
108
if(!Receive::receiving){
109
Process::start();// process data
110
Receive::start();// receive data
111
}
112
#ifdef MQTTDEF
113
if(!client.connected()){
114
reconnect();
115
}
116
client.loop();
117
#endif
118
119
#ifdef DEBUG
120
if(Serial.available()){
121
while(Serial.available())
122
Serial.read();
123
if(Dump::active)
124
Serial.println("\nDetails deactivated.");
125
else
126
Serial.println("\nDetails activated.");
127
Dump::active=!Dump::active;
128
}
129
#endif
130
}
welche Daten müsste ich jetzt mittels
1
client.publish("Temperaturwerte der Solaranlage/Puffer/Speicher");
übertragen?
Leider konnte ich die Variable, welche zu senden wäre, noch nicht
herauslesen :(
Ich wäre einer kleinen Hilfe deiner Seite sehr dankbar :)
Hallo,
Ohne mir diesen Thread durchgelesen zu haben - ich habe auf meinen ESP32
(das Programm selbst ist eigentlich für den ESP8266) folgendes Programm
geladen: https://github.com/Buster01/UVR2MQTT
Spannungsteiler für den DL-Bus dran und fertig - lief sofort problemlos
und tut es immer noch. Und genau das willst du doch, oder? DL-Bus =>
ESP8266 => MQTT wenn ich es richtig verstanden habe.
Jan H. schrieb:> Hallo,>> Ohne mir diesen Thread durchgelesen zu haben - ich habe auf meinen ESP32> (das Programm selbst ist eigentlich für den ESP8266) folgendes Programm> geladen: https://github.com/Buster01/UVR2MQTT>> Spannungsteiler für den DL-Bus dran und fertig - lief sofort problemlos> und tut es immer noch. Und genau das willst du doch, oder? DL-Bus =>> ESP8266 => MQTT wenn ich es richtig verstanden habe.
Super, vielen Dank.
Genau so etwas habe ich gesucht.
Nutzt du die Software für eine UVR1611 Anlage?
Ich habe die UVR42 und hierfür müsste man noch die Zeiten (Dauer eines
Bits, Zeitraum eines Datenrahmens) anpassen?
Ich habe die Software auf meinen ESP gespielt uns versucht mittels
Seriellen Monitor die Serial.println anzeigen zu lassen, jedoch
erscheint nur ?????. Ich habe die Baudrate auch richtig eingestellt
115200, woran könnte es noch liegen?
Hallo,
Ich habe die Schaltung mit einem cny17-4 probiert jedoch bleibt die
Ausgangsspannung bei 3,3v.
Welche Eingangsspannung hat der UVR42 damit ich den Spannungsteiler mit
auf eine 3,3v Ausgangsspannung berechnen kann?
Hallo,
ich habe wie im Bild ersichtlich die Verkabelung durchgeführt.
Wurde hier die richtige Masse gewählt?
Sind die Widerstände von mir korrekt gewählt?
Ich habe eine Eingangsspannung mit 12V angenommen und zum Teil gemessen.
Hannes D. schrieb:> Hallo,>> ich habe wie im Bild ersichtlich die Verkabelung durchgeführt.>> Wurde hier die richtige Masse gewählt?> Sind die Widerstände von mir korrekt gewählt?> Ich habe eine Eingangsspannung mit 12V angenommen und zum Teil gemessen.
ist hier meine Ansatz korrekt?
Vielen Dank.
Hannes D. schrieb:> Hannes D. schrieb:>> Hallo,>>>> ich habe wie im Bild ersichtlich die Verkabelung durchgeführt.>>>> Wurde hier die richtige Masse gewählt?>> Sind die Widerstände von mir korrekt gewählt?>> Ich habe eine Eingangsspannung mit 12V angenommen und zum Teil gemessen.>> ist hier meine Ansatz korrekt?>> Vielen Dank.
Sollte passen. die linke Schaltung mit dem Optokoppler invertiert das
Signal.
Zum Test kannst du ja ein kleines Testprogramm schreiben, welches das
Signal aufzeichnet und dann über die RS232 ausgibt.
Servus,
gibt es eine Möglichkeit den DL-Bus der TA FRISTAR2-WP auszulesen?
Lt. BDA ist eine "FWR22" als Relger verbaut.
Die Daten bräuchte ich im ioBroker. Also ggf. auch MQTT
Mfg
Hallo,
Vielen Dank an Jan H für das teilen des Projektes "UVR2MQTT"
Ich habe die Schaltung gemäß Schaltplan aufgebaut, den Code UVR2MQTT und
MQTT um username und password erweitert, sowie den Ausgang 14 des
UVR1611 als Datenleitung definiert. Zwischen dem Datenausgang und GND
des UVR1611 messe ich eine Spannung zwischen 6,7-12V und zwischen D2 und
GND des NodeMcu eine Spannung bis 1,8V.
Dem Seriellen Monitor kann ich keine Ermittlung von Daten oder den
Aufbau zum MQTT server entnehmen.
Die Infos aus dem Seriellen Monitor sehen wie folgt aus:
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00046aa0
~ld
Connecting to "SSID*"........
Status: Verbunden!
Verbindung! RSSI: -59 dBi
IP-Adresse: 192.168.xxx.xx
Receiving ... ISR not in IRAM!
User exception (panic/abort/assert)
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Abort called
stack>>>
ctx: cont
sp: 3ffffee0 end: 3fffffc0 offset: 0000
3ffffee0: 00000000 3fffff1e 0000000a 40203ec4
3ffffef0: 000000fe 00000000 00000000 00000000
3fffff00: 00000000 00000000 00000000 00ff0000
3fffff10: 5ffffe00 5ffffe00 3ffe8b6a 3ffeecbc
3fffff20: 00000000 00000003 00000004 402057ae
3fffff30: 40100535 3ffe8ae3 3ffeeb7c 402057c0
3fffff40: 40203c34 3ffe8ae3 00000004 40205cc9
3fffff50: 3fffdad0 3ffeeb40 3ffeeb7c 40203ec4
3fffff60: 3fffdad0 3ffeeb40 3ffeeb7c 40205d68
3fffff70: 31b2a8c0 00ffffff 01b2a8c0 40201ef9
3fffff80: 3fffdad0 3ffeeb40 3ffeeb7c 4020200a
3fffff90: 40208344 31b2a8c0 feefeffe feefeffe
3fffffa0: feefeffe 00000000 3ffeeca8 40205074
3fffffb0: feefeffe feefeffe 3ffe85ec 40100df1
<<<stack<<<
Was bedeutet in diesem Fall "ISR not in IRAM"?
Es würde mich freuen, wenn jemand einen Tipp hat, um das Problem zu
lösen.
Muss ich eventuell noch weitere Einstellungen am UVR1611 treffen?
Unter dem Punkt "DATENLOGGING" wird zum Beispiel der Status der
Datenleitung als "AUS" deklariert.
Vielen Dank im vorraus!
Jan H. schrieb:> Hallo,>> Ohne mir diesen Thread durchgelesen zu haben - ich habe auf meinen ESP32> (das Programm selbst ist eigentlich für den ESP8266) folgendes Programm> geladen: https://github.com/Buster01/UVR2MQTT>> Spannungsteiler für den DL-Bus dran und fertig - lief sofort problemlos> und tut es immer noch. Und genau das willst du doch, oder? DL-Bus =>> ESP8266 => MQTT wenn ich es richtig verstanden habe.
Ich habe das Programm nochmal über einen anderen Rechner aufgespielt und
eine ältere Version der library "PubSubClient.h"
verwendet. Ob dies jetzt wirklich die Ursache war kann ich nicht genau
sagen, jedenfalls funktioniert das ganze nun einwandfrei.
Falls jemand einen MQTT-Broker mit Benutzernamen und Passowort
verwendet, muss der Code wie folgt erweitert werden:
UVR2MQTT.ino -> nach der Zeile "const char* mqtt_server = "mqtt-server";
// MQTT Server" ist noch folgende einzufügen:
const char* username = "username"; // MQTT Benutzername
const char* password = "password"; // MQTT Passwort
MQTT.h -> die Zeile "mqtt_client.connect("BL-NET");" wie folgt abändern
mqtt_client.connect("BL-NET, username, password");
Carsten schrieb:> Was bedeutet in diesem Fall "ISR not in IRAM"?
Hi Carsten,
bekommst du diese Meldung noch immer? Mein Output ist unten angeführt.
Ich denke es werden auch keine MQTT Nachrichten versendet.
Versuche gerade die Kombi ESP8266 mit einem ESR31 meiner
Solarthermieanlage zum Laufen zu bekommen. Habe einen ESP von Adafruit
(Huzzah) und habe den Optokoppler genauso aufgebaut wie von Hannes D.
gezeichnet. Leider habe ich kein Oszi um die Signale zu kontrollieren,
nur ein Multimeter.
Muss ich für den ESR31 im Gegensatz zum UVR1611 noch etwas am Code
ändern?
Vielen Dank im Voraus.
Wil schrieb:> Wil schrieb:>> Muss ich für den ESR31 im Gegensatz zum UVR1611 noch etwas am Code>> ändern?>> Vielen Dank im Voraus,> Wil
So, nun bin ich wieder etwas schlauer.
Um sicher zu gehen, dass auch wirklich brauchbare Daten am ESP ankommen
habe ich mit einem Oszi vor und nach dem Optokoppler die
Spannungsverläufe kontrolliert.
Damit konnte ich auch die Zeitverläufe aufzeichnen (siehe Anhänge) und
habe gelernt, dass wie in der von Harald P. @haraldp mitgeschickten
Beschreibung ("DLAnz.zip (1010 KB)") Daten mit bestimmter Frequenz in
"Datenrahmen" geschickt werden. Sowohl die Frequenz als auch die
Länge/Inhalt der Datenrahmen ist für den ESR31 anders als beim UVR1611.
Leider ist der ESR31 in der Beschreibung nicht enthalten. Ich vermute
aber dass er mit XY Hz sehr viel weniger Bytes schickt als der UVR1611
(488Hz).
Sehe ich es richtig, dass die Übertragungsrate ~250Hz ist (siehe
Bildschirmfoto_von_2023-12-28_11-44-23.png)? Das passt irgendwie zu
keinem der sonst dokumentierten Übertragungs-frequenzen von 50Hz oder
488Hz.
Das mit angezeigte Dekodieren mit dem Oszi funktioniert noch nicht
richtig.
BG
Wil
Guten Morgen Zusammen,
ich bekomme das ganze leider nicht zum laufen.
Habe eine UVR16x2 mit DL-Bus (12V). Diesen habe mit entsprechenden
Spannungsteiler (entsprechend der Schaltung von hier:
https://espeasy.readthedocs.io/en/latest/Plugin/P092_UVR1611.html#p092-uvr1611-page)
an meinen ESP32 angeschlossen. Leider liefert ESPEasy keine Daten, da
laut den Logs konstant Daten empfangen und entsprechend verarbeitet
werden müssen (p092_read: Still receiving DL-Bus bits! -> Zeile 564 in
https://github.com/letscontrolit/ESPEasy/blob/mega/src/_P092_DLbus.ino).
Habe mit einem "Oszi" mal die Signale gemessen und angehängt.
Habt ihr eine Idee was falsch ist?
Als alternative wollte ich die Schaltung dann mal mit einer anderen SW
nutzen (https://github.com/Buster01/UVR2MQTT), allerdings bekomme ich
die nicht kompiliert (für den ESP8266 und/oder ESP32).
Welche Libraries (und Versionen) müssen denn eingebunden werden?
Danke euch für eure Hilfestellung!
SL
Ich habe das zwischenzeitlich gelöst und den Code etwas optimiert, das
vorgehen und den Anschluss dokumentiert.
Vielleicht hilft das dem einen oder anderem weiter.
https://github.com/stoffelll/UVR2MQTT
VG
SL
Hallo,
bekommst du damit auch die Volumenströme von FTS-DL - Sensoren am DL-Bus
übertragen?
Problemlos für den ESP32 zu compilieren?
Ich nutze momentan ESPeasy mit meiner UVR1611. Bekomme aber diese
Volumenströme nicht und möchte demnächst wohl auch auf die UVR16x2
umsteigen.
Danke dir,
Thomas
Hi Thomas,
der Volumenstrom liegt auf jedem Fall auf dem Bus, allerdings habe ich
die Protokoll-Auswertung nicht erweitert (mangelnde Zeit und Kompetenz).
Bzgl. ESP32:
Habe ich nicht versucht, gehe aber davon aus, dass das jetzt auch
funktionieren wird.
VG
SL
Chris schrieb:> Ich habe das zwischenzeitlich gelöst und den Code etwas optimiert, das> vorgehen und den Anschluss dokumentiert.
Danke - habe das bei mir recht einfach auf den ESP8266 bekommen!
Bei mir ist ein UVR610K im Einsatz
https://www.ta.co.at/x2-frei-programmierbare-regler/uvr610k-ohne-display,
welcher Warmwasser-Ladung und Fußbodenheizung für eine enerboxx premium
Hybrid regelt (dezentrale Warmwasserbereitung im Mehrfamilienhaus)
https://pink.co.at/enerboxx-hybrid/
Zudem hängt am DL-Bus noch ein Raumsensor RAS+DL
https://wiki.ta.co.at/RAS%2BDL (wird nur für Werte-Anzeige genutzt sowie
um die Warmwasserbereitung an- bzw. abzuschalten, im Urlaub z. B.)
Die Sensorwerte 1-5 sind gefüllt, alles andere ist leer.
Sensor2 ist für mich der wichtigste Wert (Temperatur Brauchwasser).
Interessant wäre, ob man durch den ESP auch die Freigabe der
Brauchwasser-Ladung realisieren könnte.
Chris schrieb:> Hi Thomas,>> der Volumenstrom liegt auf jedem Fall auf dem Bus, allerdings habe ich> die Protokoll-Auswertung nicht erweitert (mangelnde Zeit und Kompetenz).>> Bzgl. ESP32:> Habe ich nicht versucht, gehe aber davon aus, dass das jetzt auch> funktionieren wird.>> VG> SL
Hat das jemand geschafft, den sensorwert vom Bus zu lesen oder gar neue
sensorwerte auf den Bus zu schreiben?
Auch wäre es interessant zu wissen, was der Wert „WMZ1currentPower“
bedeutet.
Hat hier jemand mehr Infos?
Hallo Harald!
Versuche gerade auf Basis Deines Codes meine UVR1611 per DL-Bus aus zu
lesen.
Hierzu verwende ich einen Arduino Uno + Optokoppler H11L1 mit Rv=4,7k
und R_PullUp=1k.
H11L1 Datenblatt:
https://cdn-reichelt.de/documents/datenblatt/A200/ZD630633.pdf
Ich habe die Anpassungen für 16MHz Takt im Code (abgespeckte Version)
auf Basis Deiner Angaben
(Beitrag "Re: UVR 1611 (TA), Auswertung DL, Mega88, WinAVR") gemacht.
Ich empfange nur Mist und erhalte ständig Prüfsummenfehler.
Siehe Serial-Log im Anhang.
Ich habe am DL-Bus noch einen Raumsensor (RAS+DL) hängen. Eventuell
macht der Probleme. Aber die UVR sendet ja trotzdem im Loop ihre
Datenrahmen.
Kann es sein, dass ich die ganze Zeit die Masteranfrage empfange 0x00
anstatt die Gerätekennung 0x80?
Siehe neueres Dokument zu DL-Bus mit Version 1.7, Seite 15 im Anhang!
Leider sind meine Programmierkentnisse noch nicht ausreichend, um Deinen
Code vollständig zu verstehen.
Wäre es bitte Möglich den Ansatz mit Timer0 und Dein Vorgehen im Code
mit ein paar Sätzen zu erklären?
Du hast das DL-Signal nach dem Optok. an INT0 angeschlossen und
detektierst hier per ISR jede steigende Flanke. In der ISR suchst Du
zunächst nach den 16 High-Bits zur Synchronisation. Soweit so gut, dann
steige ich leider aus.
Auch bei den Angaben der TA zum DL-Bus habe ich einige
Verständnisprobleme:
Z.B.:
- Datenrahmen der UVR1611: Byte#0: Sync mit 16 High-Bit.
Seit wann hat ein Byte 16 Bit? Das sind doch 2 Byte.
- 1/488Hz = 2,049msec und nicht 2,048msec
- Zeitraum für einen Datensatz: 16 High-Bit + 64Byte Daten mit je 10Bit
+16 High-Bit ergeben bei
mir 16 + 640 + 16 = 672 Bit x 2,048msec = 1,38 sec und nicht 1,35 sec
wie im Datenblatt angegeben.
Hast Du eine Idee, warum ich nur Mist empfange?
Danke!
Grüße
Rick
Auf die Schnelle - ohne, dass ich mir alles im Detail angesehen habe.
Überprüf mal, ob das DL-Signal die richitige Polarität hat. Bei mir ist
der Optokoppler anders beschaltet.
Harald
Hallo Harald!
Das DL-Signal wird durch den Ausgangstransistor an der UVR1611
invertiert und durch den Optokoppler auch wieder invertiert.
Somit müsste das Signal stimmen. Siehe Truth-Table im Anhang.
Du benutzt den internen Pull-Up-Resistor des AVRs, ich habe einen
externen Pull-Up , weil das der Optokoppler so verlangt.
Gruß
Rick
Hallo Harald!
Hab den "Fehler" gefunden.
Das Auslesen des Logging-Datensatzes der UVR1611 mit Deinem Code
funktioniert nur, wenn am DL-Bus keine Sensoren angeschlossen sind.
Sobald Sensoren am DL-Bus hängen, so wie bei mir der RAS+DL, macht die
UVR1611 (als Master) Slave Anfragen und die Startbedingung des
Logging-Datensatzes kann anscheinend nicht mehr korrekt erfasst werden.
--> Siehe DL-Bus-Doku in Version 1.7, Seite 15:
Beitrag "Re: UVR 1611 (TA), Auswertung DL, Mega88, WinAVR"
Leider kapiere ich Deinen C-Code der beiden ISR-Routinen zum Erfassen
der Startbedingung und Lesen der Daten immer noch nicht wirklich und
kann somit auch den Code nicht dementsprechend anpassen.
1
if (TCNT0>80 || TIFR0 ) // TCNT0=64: 64*32us = 2048us
Warum hier 80x32usec? und die Oder-Verknüpfung mit dem Timer Interunpt
Flag Register
Rick M. schrieb:> Leider kapiere ich Deinen C-Code der beiden ISR-Routinen zum Erfassen> der Startbedingung und Lesen der Daten immer noch nicht wirklich und> kann somit auch den Code nicht dementsprechend anpassen.
Hallo Rick,
ich habe den Code 2007 entwickelt, also vor 17 Jahren. Leider habe ich
die Unterlagen, die ich damals für die Analyse des Protokolls erstellt
habe, nicht wiedergefunden. Ich müsste also wieder von vorn anfangen.
Da die Geräte, die den DL-Bus auswerten (3 unterschiedliche
AVR-Kontroller) nach wie vor störungsfrei laufen, sehe ich keinen
Anlass, am Code etwas zu ändern. Kann schon sein, dass Unstimmigkeiten
da sind.
Da du sowieso den Code anpassen musst - wegen zusätzlicher DL-Geräte -
schlage ich vor, dass du die Analyse allein durchführst.
Die drei genannten Geräte sind Teil meiner selbst entwickelten
Hausautomatisierung. Daneben gibt es noch ca. 40 weitere aktive
Teilnehmer, die entweder den AVR oder ESP8266, den ESP32 oder den RP2040
nutzen.
Harald
Hallo Harald!
Ich habe den Grund gefunden, warum immer nur die Masteranfrage gefunden
wird.
Komischerweise greift die SYNC-Suche immer auf den SYNC vor der
Masteranfrage der UVR1611, obwohl lt. meinen Messungen die beiden SYNC
(Master und Datenlogging) gleich sind.
Der Datenrahmen der Masteranfrage ist lediglich 3 Byte inkl. Prüfsumme.
Da aber hier der Datenramen mit 65 Byte definiert ist, wird der SYNC für
den Datenrahmen des Loggings der UVR zeitlich verpasst weil dieser
bereits 256msec nachher eintritt (Bei 1 DL-Sensor).
Ich habe eine variable Datensatzlänge in Abhängigkeit von der
Gerätekennung programmiert:
Byte#0: 0x00 = Masteranfrage --> 4 Byte
Byte#0: 0x80 = Logging-Datenrahmen --> 65 Byte
Nun funktionierts, beide SYNC werden gefunden und die Datenrahmen
korrekt ausgelesen. Im Oszi-Bild sieht man auch schön die 40msec Pause
bevor der Sensor mit geringerer Spannung antwortet + die 256msec Abstand
zw. den SYNCs mit 16 x 1msec High.
Ich versuche gerade die Sensordaten richtig aus zu werten.
Da komme ich beim Maskieren ziemlich ins straucheln. Ich muss jeden
einzelnen Wert in HEX umrechnen.
Leider habe ich keine Ahnung wie der Temperaturwert des Raumsensors
richtig in einen integer Wert umgewandelt werden muss. Das wird im
Datenblatt einfach verschwiegen, bzw. ich kapiers nicht.
In Deinem Code finde ich nur die Maskierung bez. neg. Temperaturwert
Hast Du auf den Rest verzichtet, oder übersehe ich es lediglich?:
1
uint8_t i;
2
for (i=0; i<16; i++) // Umwandlung in Integer
3
{
4
if (DLWerte.t.Temp[i]&0x8000) DLWerte.t.Temp[i] |= 0xF000;
5
else DLWerte.t.Temp[i] &= ~0xF000;
6
}
Könntest Du da eventuell bitte mal einen Blick auf meinen Code werfen?
DL-Bus Protokoll Seite 11.
Danke!
Gruß
Rick
@rick00:
Nur damit ich es hier für die Nachwelt festhalte: Ich habe einen UVR610
(ja, andere Voraussetzungen wie bei dir) und angeschlossenem RAS+DL am
DL Bus - mit ESP8266 (https://github.com/stoffelll/UVR2MQTT)-
funktioniert(e) ohne Nacharbeiten.
Hallo,
ich habe mich soweit in das Thema mit dem DL Bus eingelesen, hätte aber
noch eine Frage zu den Optokopplern...
Angenommen ich verwende einen
CNY17-4, SGH610 oder einen H11L1....
Welche Widerstände verwende ich nun am Eingang und als Pullup?
Wiederstand am Eingang 1k, 4,7k oder 6,8k?
Pullup 1k, 10k oder 47k?
Beschrieben werden hier ja verschieden Varianten(CNY-17 Vorwiderstand
mit 1k oder 6,8k; Pullup 10k oder 10k-47k; H11L1 Vorwiderstand 4,7k;
Pullup 1k)
wann nehme ich was/warum nehme ich welchen Widerstand?
Ich würde mich freuen zu diesem "alten" Thema noch eine Antwort zu
erhalten :)
Vielen Dank!