Das Problem habe ich jetzt schon mit der aktuellen alten Version. Ich
nutze allerdings so n China Modbus TCP Gateway und vermute dass
Verbindungsprobleme dann eher daher rühren. (Die Troviskomponente crasht
mit Exceptions in C# Modulen). Muss teilweise 2,3x eine Übertragung
machen. Daher bin ich auch etwas zurückhaltend mit dem
Firmwareupgrade...
Ich starte Trovis mit der Config für meine 5576, v2.20-v2.29, habe 2.26
im Gerät, dennoch kommt der Dialog zur "Konvertierung".
@MartinM Wie bist du mit dem Regler verbunden beim Update? Über den
offiziellen USB-Converter 3 oder auch eine Non-Name Modbus Lösung?
Modbus Lösung
Genauer:
Mein 5573 Regler ist über ein USB-TTL Converter (Waveshare USB to
RS232/485/TTL) an einen Raspi verbunden, der wiederum über mbusd ein
Modbus TCP Gateway anbietet. Läuft bisher stabil.
Ich weiß aber noch nicht wie ich die Werte am einfachsten loggen kann.
Habe noch kein SmartHome System.
Hallo Allerseits,
Bin auch auf der Suche nach einer Kommunikation zu unserem 5579 Regler.
Leider hängt an der seitlichen RJ45 schon ein SACO55 (1400-9771) zur
Verbindung an die Fernheizungsleitzentrale.
Kann ich trotzdem an die Daten kommen? ev über die Frontbuchse, wie ist
dort die Pinbelegung?
Gruß
Simon
Habe da auch mal eine Frage zum Flashen.
Ich nutze ein Wemo mit esp-link generell zum auslesen der Werte fürs
SmartHome
Zum konfiguieren gehe ich via mbusd und Trovis Viewer auf die Anlage,
das funktioniert ohne fehler.
Das flashen hingegen bricht leider immer ab.
Bootmanager 1.62.
Hat das jemand schon darüber erfolgreich hinbekommen? Alternativ hab ich
noch ein USR-TCP232-T2 liegen, den ich analog statt den wemo sonst mal
anschließen würde.
Lieben Gruß
Sebastian
Den USR habe ich auch - mit den oben erwähnten Problemen mit TV. Falls
Du’s damit erfolgreich hinkriegst, sag bitte Bescheid! Ich komme im
Moment leider nicht zum Testen. Vielen Dank!
also update erfolgreich durchgeführt mit dem USR Modul
Eingestellt hab ich ihn wie hier in der Wiki
https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki/Schritt-2:-Adapter-einrichten
Habe auch die alte VCOM software installiert!!
TroviewViewer selbst wollte mit meiner Anlage nicht reden, der Updater
hat aber erfolgreich erst 251 geschrieben dann 261.
251: weil der bei Samson noch angeobten wird. Ich weiß nicht ob es ein
notwendiges übel ist. Bin von 214 gestartet.
Mal schauen ob der Troview Viewer noch den USR mag ( auch wenn das keine
Dauerlösung ist, möchte nämlich kein LAN Kabel liegen lassen )
Ansonsten gehts gleich zurück auf den WeMo
[EDIT]
Windoof reboot ist und bleibt das Wundermittel. Darum nutz ich windows
schlicht nicht **g**
Also geht nun auch mit TrovisViewer via USR direkt COM x - Viewer macht
nur bis 2.59 also gibt es eine Meldung dass er 2.61 konvertiert. Seis
drum...
OFFTOPPIC Frage an ALLE
Mein VF1 ( Vorlauf ? ) liegt bei 22° und mein RüF ( Rücklauf ? ) bei
35.2 °
Ist das normal? Nie gedanken gemacht
Wäre sonst ja entweder Sensor Defekt oder seit Anfangan ( vor 4 Jahren )
falsch angeschlossen ??
Hab im Winter auch immer Probleme und darum angefangen die Daten zu
Loggen letztes Jahr.
[/EDIT]
> Mein VF1 ( Vorlauf ? ) liegt bei 22° und mein RüF ( Rücklauf ? ) bei> 35.2 °> Ist das normal? Nie gedanken gemacht> Wäre sonst ja entweder Sensor Defekt oder seit Anfangan ( vor 4 Jahren )> falsch angeschlossen ??
JAin, also VF1 ist fast immer Vorlauf und RüF1 fast immer Rücklauf im
Heizkreis 1. Wo genau die Sensoren angelegt sein müssen, ist abhängig
von der Anlagenkennziffer. Die wählt man im Trovis aus. Zu jeder Anlage
gibt es im Handbuch ein Anlagenschema, ist eine sehr wichtige Grafik
Deiner Anlage, die der Trovis steuern soll. Aber das kennst Du
wahrscheinlich. Also: Anlagenschema ansehen und gucken, wo der Sensor
angelegt sein muss.
Auf den ersten Blick würde ich sagen: Die Verkabelung Deiner Sensoren
passt nicht. VF1 klingt nach RF1 oder AF1 Mittags bei Sonnenschein, RüF1
könnte passen.
Es sei denn, Du betreibst damit eine Wärmepumpe .. (Scherz)
Bin aber kein Experte, nur so ein erster Gedanke
Rico L. schrieb:>> Mein VF1 ( Vorlauf ? ) liegt bei 22° und mein RüF ( Rücklauf ? ) bei>> 35.2 °>> Ist das normal? Nie gedanken gemacht>> Wäre sonst ja entweder Sensor Defekt oder seit Anfangan ( vor 4 Jahren )>> falsch angeschlossen ??>> JAin, also VF1 ist fast immer Vorlauf und RüF1 fast immer Rücklauf im> Heizkreis 1. Wo genau die Sensoren angelegt sein müssen, ist abhängig> von der Anlagenkennziffer. Die wählt man im Trovis aus. Zu jeder Anlage> gibt es im Handbuch ein Anlagenschema, ist eine sehr wichtige Grafik> Deiner Anlage, die der Trovis steuern soll. Aber das kennst Du> wahrscheinlich. Also: Anlagenschema ansehen und gucken, wo der Sensor> angelegt sein muss.
Tatsächlich Nein.
Also die Kennziffer gibt er mir mit. 10. zurück.
Dann schau ich im Handbuch nach Anhang x wo Anlage 10. steht ?
Ob das dann meiner Anlage entspricht :/
>> Auf den ersten Blick würde ich sagen: Die Verkabelung Deiner Sensoren> passt nicht. VF1 klingt nach RF1 oder AF1 Mittags bei Sonnenschein, RüF1> könnte passen.
AF1 ist Außensensor, der paßt aktuell mit 15° Nordseite.
An der Alpha2 Pumpe sind ja auch zwei Temperatur anzeigen. Die den Werte
der Trovis entsprechen, nach meinem verständnis dann auch falsch rum
anzeigen.
Die Pumpe kommt an den VL ?
> Es sei denn, Du betreibst damit eine Wärmepumpe .. (Scherz)>> Bin aber kein Experte, nur so ein erster Gedanke
Das Schema für Anlagenkennziffer 1.0 ist bei meinem Handbuch (sorry,
Handbuch für alte Firmware V1.4) auf Seite 30. Bei neueren Handbüchern
irgendwo später.
Außerdem findet man die Grafik mit dem ausgewählten Schema auch in der
Software Trovis View 4.x, wird im Reiter Anlagenkennziffer angezeigt.
Ohne Anlage/Anlagenkennziffer weiß der Trovis nicht, was er mit den
Sensoren machen soll.
Bin vermutlich nicht der Richtige für Erklärungen, so gut kenne ich mich
auch nicht aus.
Rico L. schrieb:> Bin vermutlich nicht der Richtige für Erklärungen, so gut kenne ich mich> auch nicht aus.
Durchaus scheint es mir mehr Know-How als bei mir.
Anbei mal die Schematic vom TroviewViewer und ein Bild meiner Anlage.
37° und 45° zeigt er mir als Vorlauf bzw Rücklauf an. Finde die Werte
tatsächlich aber auf keinem meiner mechanischen Temperaturanzeigen
Vielleicht ein Idee? Ansonsten muss ich wohl mal direkt ein Sanitär
Monteur damit beauftragen :(
[EDIT]
TrovisViewer sagt übrigens 1.0-1
[/EDIT]
Hallo, vielleicht wuerde es helfen, wenn Du kurz beschreibst, wie Deine
Heizungsanlage aussieht. Hast Du z.B. keinen WW-Speicher, welcher vom
Trovis angesteuert wird? Ich habe z.B. eine ziemliche Std-Anlage:
Fernwaerme, 1 Rk fuer die Heizung und einen WW-Speicher, der vom Trovis
ueberwacht wird. Es kann bei mir nur entweder die Heizung oder die
WW-Aufbereitung laufen. Ich glaube es ist der Anlagentyp 2.1 (kann aber
gerade nicht schauen).
Wenn Du z.B. eine Solarthermieanlage auf dem Dach hast oder eine FBH
(zusaetzlich/alternativ) sieht es wieder anders aus: dann hast Du ggf. 2
Regelkreise und entsprechend mehr Fuehler/Sensoren.
Kurz noch eine Frage zum FW-Update: Ich scheine den gleichen USR wie Tom
Bombadil zu haben. Ist das FW-Update bei Dir auf Anhieb durchgelaufen?
Weiss jemand, ob es ein Fail-Safe gibt, falls der MODBUS-TCP Umsetzer
doch mittendrin meint, nicht richtig zu vermitteln? Ist die Anlage dann
hin oder wird der interne Update erst gestartet wenn das Firmware-File
erfolgreich uebertragen wurde? Bei Dir funktioniert jetzt auch mit
TrovisView alles nach einem Reboot, habe ich das richtig verstanden?
OK, also Kurz zur Anlage:
eine POWO Kompaktanlage.
Heizung durch Fernwärme.
Ein Wärmetauscher ( s.Bild ) und befeuert wird eine FBH mit der Alpha2
und ein 250l Wasserspeicher für warmes Wasser im Haus.
Wird aber nicht von der Trovis gesteuert oder überwacht. Dafür hat die
Anlage ein normalen Heizungsdrehventil ( oder wie die teile heißen die
an einem Heißkörper sind) und steht auf 4. Also Bimetal das dann den
Fluss steuert.
Keine Solartherme o.Ä. Auf meinem Bild ist eigentlich bis auf der Trovis
und der Warmwasserspeicher, sowie der Wärmezähler, alles zu sehen.
Gibt nur 1 Kreis der eingestellt ist in der Trovis PA1 bzw CO1
In einer alten backup config, die ich geladen habe, stehen auch die
Werte zum Zeitpunkt des auslesens vom AF,VF,RüF. Da war RüF < VF :/
Ob es ein Fallback gibt weiß ich nicht. Im Bootmanager ist der haken
gesetzt, dass das übertragen im Hintergrund stattfinden soll.
Tatsächlich sah es im Bootmanager eher noch onDemand aus.
Flags wurden gesetzt, Speicher gelöscht, und dann Programmiert.
Das Modul macht aber ja ein ethernet to ttl. also brauchst du auch den
vcom und programmierst dann via "com port x" und nicht via modbus-tcp.
Ich hatte eher bange, dass die vcom software abstürzt.
Also auf meinen Modbus TCP GW komme ich nur via TCP/Web direkt. Ich hab
keinen VCom? Auch noch nie gebraucht bisher..?
Deine Anlage: Hmm ich fürchte, ich kann Dir da dann nicht helfen :-/ ich
bin froh, dass ich inzwischen halbwegs verstehe wie meine Anlage
funktioniert und aus welchen Komponenten sie besteht :-/ Ich wundere
mich aber, dass Dein WW Speicher zB gar nicht über die Trovis läuft…
Haette jetzt gedacht, dass mein Setup vermutlich noch das Einfachste
ist, dass man aufbauen kann.
Es kann aber durchaus vorkommen dass der VL<RL ist - physikalisch
natürlich nicht, aber je nachdem wo der RL gemessen wird. Ich erfasse
auch VL/RL am Waermemengenzaehler (also separat, nicht über die Trovis)
und da ist teilweise eine ganz schöne Differenz! Mein Rk1 RL Sensor ist
AFAIR an der gleichen Position verbaut wie der WWZ während der Rk1 VL
deutlich nach dem Wärmetauscher hängt. Man hat mich aber überzeugt, dass
das so richtig wäre.
Mit dem Trendviewer (das ist ein Reiter in der Android App TROVIS 55Pro)
kann man sich die letzten 14 Tage der Sensoren im Trovis auslesen. Anbei
ein Screenshot einer 2.1 Anlage. Man sieht schön die beiden Peaks Abends
wenn geheizt wird und morgens wenn das Brauchwasser erwärmt wird. Die
gelbe Linie oben ist die Außentemperatur wie sie die letzten Tage
heruntergegangen ist.
Es gibt schon 'mal Momente, wo RüF über VF ist, sollte aber selten sein.
Nach vernünftigem Hydraulischem Abgleich sollte es eigentlich nicht mehr
vorkommen. Beziehungsweise nur noch kurz nachdem ein WW-Speicher geladen
wurde.
Ansonsten besser den Heizungsfachmann kommen lassen.
Rico L. schrieb:> Man sieht schön die beiden Peaks Abends> wenn geheizt wird und morgens wenn das Brauchwasser erwärmt wird.
muss mich korrigieren: der erste Peak kam auch vom WW-Speicher. SF1 fiel
gegen 18:00 Uhr unter das Speichersoll und wurde wieder aufgeheizt.
Hallo Martin.
ich verweise on top noch auf die register/coils von Tom, der denk ich
auch Grundlage geschaffen hat für das Modbusmodul in fhem
https://github.com/Tom-Bom-badil/samson_trovis_557x/tree/master/templates
Ich habe auch eine 5573-001 und nutze die register dafür. Habe mir auch
ein "eigenes" Modbusmodul auf Grundlage vom 5576 gebaut, da ich nicht
alle Werte brauchte bzw andere ...
In FHEM wird das 98_Modbus.pm implementiert und dann die
h(olding)register bzw die c(oils) entsprechend adressiert ...
1
'h9' => { reading => 'Aussen_Temp',
2
name => 'AußentempAF1',
3
expr => '$val/10',
4
format => '%.1f',
5
unpack => 's>',
6
poll => 1
7
}
8
...
9
10
'c1008' => {reading => 'RK1_Frostschutzbetrieb',
11
name => 'FrostschutzRk1',
12
map => '0:Aus, 1:An',
13
poll => 1
14
},
Die Funktion read_register in deinem minimalmodbus perl modul
1
read_register(registeraddress: int, number_of_decimals: int = 0, functioncode: int = 3, signed: bool = False) → Union[int, float]
Danke euch beiden. Werde mit den Register von Tom weitermachen.
Und noch eine Frage:
Ich habe meinen Regler per TTL USB Adapter an meinem RPi angeschlossen.
Wenn ich den mbusd Service laufen lasse (für Trovis App und View),
bekomme ich dann bei Zugriffsversuch per minimalmodbus die folgende
Fehlermeldung:
1
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Offensichtlich ist nur ein gleichzeitiger Zugriff möglich.
Kann ich das durch einen Serial to Ethernet converter (USR-DR301)
lösen?
PS: Es gibt eine neue Trovis View Version (4.80)
Wenn man im Trovis View auf die Wurzel im Baum (ganz oben links)
Rechtsklickt ("Heizungsregler Trovis 55..") dann kann man EXPORTIEREN ..
als XML speichern.
Wenn man nun zuvor seinen Heizungsregler einmal ausliest, wird genau für
diese Firmware der Baum aufgebaut. Beim Exportieren landet dann im XML
die Liste der für diesen Regler/Firmware relevanten Register (denke
ich).
Ich habe einen USR-DR301 über ModBus TCP angeschlossen und greife
manchmal gleichzeitig über das Hausnetz per PC per Trovis View und von
außen per Android App Trovis 55xx Pro auf den gleichen Regler zu. Vom
Grundsatz gibt es zwar keine Fehlermeldungen, aber man merkt schon
deutlich, dass was nicht stimmt. Der Trendviewer bleibt immer wieder
stehen, es hakt und dann geht es mal hier mal da weiter ...
Hallo zusammen,
ich habe meinen 5573-1 von 2.52 auf 2.61 gehoben. Seitdem kann ich mit
der App „Trovis 55Pro“ für den WW-Kreis die Betriebs-Modi nicht mehr
ändern.
Vorher konnte ich zB von Auto auf Nacht schalten; es wurde dann auf der
HP des Reglers das GLT-Symbol angezeigt und der Modus umgeschaltet.
Jetzt wird merkwürdigerweise nur noch das GLT gesetzt.
Auf dem Rk1 funktioniert alles wie gewohnt???
Hat jemand eine Idee?
Hallo in die Runde,
nach längerer Zeit mal wieder eine Rückmeldung von mir, gepaart mit
einer Bitte.
Das Wiki scheint recht gut genutzt zu werden, und durch seine
Informationen gibt es mittlerweile mehrere Neu-Apdationen für FHEM,
Loxone, openHab und sogar den ESP8266 (sowie mehrere weitere
'Privat'projekte in C, C#, Pyhon etc).
Derzeit erreichen mich wieder viele (Neu-)Anfragen hinsichtlich der
Trovis, mindestens ein bis zwei pro Woche. Dabei geht es oft um Modelle,
die anfangs nicht funktionieren (z.B. 5573-001), um neue Adapter (z.B.
für die Hutschiene) oder neue Anbindungen (natives RS485, KNX-Anbindung,
'echte' Hardware-Modbus-Server etc).
Ich helfe immer gern - möchte aber die kommende Winter-Bastelzeit dazu
nutzen, den Aufwand dafür etwas zu reduzieren, indem ich Informationen
strukturiere und das Wiki als zentrale Wissensbasis für uns alle
erweitere.
Meine Bitte: Ich habe auf Github ein 'Issue' für funktionierende
Konfigurationen erstellt:
github.com/Tom-Bom-badil/samson_trovis_557x/issues/3
Ich freue mich über jeden, der sich 5 Minuten Zeit nimmt und in einem
Kommentar kurz die Eckdaten seiner funktionierenden Konfiguration
posted. Für nicht funktionierende Dinge bitte gern auch einen separaten
Issue aufmachen, damit wir das Problem lösen können. Vielen Dank im
Voraus!
/tom
p.s. Daneben habe ich mir gerade diese Woche eine Bastel-5579 sowie
diverse verschiedene Adapter für die Winterzeit bestellt - Informationen
über laufende Projekte, neue getestete Adapter, neue Implementierungen
usw. dann wie gewohnt ebenfalls im Wiki unter
github.com/Tom-Bom-badil/samson_trovis_557x/wiki
Danke! :)
Hey Tom,
danke für die Referenz auf mich auf deiner Wikiseite.
Bzgl. dem von Dir beschriebenen Verhalten: "--> Problembehebung
simultaner Zugriff einarbeiten #ToDo"
Wenn ich Dein Aufbau richtig interpretiere, versuchst du auf eine
"serielle" Schnittstelle (der TTL2USB Konverter ist soweit ich weiß als
serial TTY Device in Linux angebunden, verhält sich also wie eine RS232
Schnittstelle), von zwei verschiedenen Prozessen aus zuzugreifen. Das
dürfte ohne explizite Synchronisation nicht funktionieren. Mögliche
Synchronisation könnte bspw. sein ein Prozess schreibt, einer liest,
aber nicht beide beides. Oder alternativ exclusive open via TIOCEXCL,
und dann nach jedem Zugriff die Schnittstelle wieder schließen und im
anderen Prozess so lange warten bis open nicht mehr EBUSY zurückgibt.
Siehe:
https://stackoverflow.com/questions/8745948/how-can-you-access-a-serial-port-from-two-different-processes-python
Daher würde ich empfehlen nur mbusd auf das /dev/tty Interface zugreifen
zu lassen und die restlichen Zugriffe über das IP Interface von mbusd zu
machen. Ohne jetzt in den Source Code von mbusd geschaut zu haben, würde
ich vermuten, dass dort eine entsprechende Serialisierung der Zugriffe
erfolgt und damit das ganze richtig synchronisiert wird.
Danke Volker,
ich geh über LAN und /tty/trovis drauf, nicht über USB - da müssten
eigentlich simultanene Zugriffe möglich sein.
Ich muss ohnehin mein Plugin anpassen - dann mache ich es lieber gleich
richtig und greife direkt per IP auf den Modbus-Server des LAN-Adapters
zu. ;)
Ist in Arbeit, Bastel-5579 samt mehrerer neuer Adapter wird die Woche
geliefert (eBay ist wie leergefegt von den Dingern) ...
/tom
Ich habe zusammen mit jeroenst an einer Tasmota-ModBus-Bridge
gearbeitet:
https://tasmota.github.io/docs/Modbus-Bridge/#additional-commands-for-use_modbus_tcp_bridge
Damit hängt man lediglich einen billigen ESP-01 an den 557x und kann
folgendes gleichzeitig (Modulkonf. "ModBr TX/RX"):
* per ModBus-TCP auf 557x lesen/schreiben
* per MQTT auf 557x lesen/schreiben
* per Tasmota-Konsole auf 557x lesen/schreiben
Oder man konfiguriert auf "None" dann per SML:
https://tasmota.github.io/docs/Smart-Meter-Interface/#trovis-557x-modbus
Damit wird der 557x regelmäßig abgefragt und die Werte werden
automatisch per MQTT verschickt (und somit --> InfluxDB --> Grafana
etc).
Das muss jetzt nur noch umfassend dokumentiert werden ;-)
Hallo Jens,
danke für die Arbeit - ich habe Euer Projekt drüben auf Git 'live'
verfolgt und immer fleißig mitgelesen und Euch auch schon eine Weile im
Wiki verlinkt. :)
Die Idee mit dem ESP gibt es ja schon lange, jetzt hat es endlich mal
einer durchgezogen! Was mir fehlte, war eine klare Ansage "Jetzt läuft
TrovisView komplett!", sonst hätte ich wohl schon längst einen der hier
rumliegenden ESP's mit Tasmota versehen - auch wenn ich eher aus der
ESPEasy-Fraktion komme. ;)
Noch eine neue Baustelle für die Bastel-Trovis, bisschen Doku fällt
nebenbei sowieso immer ab ... ;)
Nochmal danke an jeroenst und Dich für Eure Arbeit,
/tom
Hi Tom,
mir fehlte bis jetzt noch die Zeit für einen abschließenden Test.
Wirklich der Hammer, was mit dem ESP alles möglich ist.
SML läuft bei mir schon dauerhaft. Und die ModBus-Bridge funktioniert ja
auch schon. Kann also bereits in evtl. neue Dokumentationen aufgenommen
werden. Ich werde den o.g. Test demnächst noch durchführen.
VG
Volker V. schrieb:> Wenn ich Dein Aufbau richtig interpretiere, versuchst du auf eine> "serielle" Schnittstelle (der TTL2USB Konverter ist soweit ich weiß als> serial TTY Device in Linux angebunden, verhält sich also wie eine RS232> Schnittstelle), von zwei verschiedenen Prozessen aus zuzugreifen. Das> dürfte ohne explizite Synchronisation nicht funktionieren. Mögliche> Synchronisation könnte bspw. sein ein Prozess schreibt, einer liest,> aber nicht beide beides. Oder alternativ exclusive open via TIOCEXCL,> und dann nach jedem Zugriff die Schnittstelle wieder schließen und im> anderen Prozess so lange warten bis open nicht mehr EBUSY zurückgibt.
Genau dieses Problem habe ich durch
'https://github.com/danielinux/ttybus'; lösen können, was jetzt seit 1,5
Jahren stabil seinen Dienst bei mir tut um einen Jeelink gleichzeitig
für FHEM als auch für meinen eigenen Parser zugänglich zu machen und die
Daten via MQTT weiterzureichen. Die Konfiguration ist etwas fummelig,
aber wenn es tut, dann tut es.
Im Prinzip hast Du mit dem Tool eine Art Y-Weiche, so dass mehrere
Prozesse gleichzeitig lesend und schreibend auf ein serielles Interface
zugreifen können. Wenn Bedarf besteht, kann ich mein Setup/Konfig
sharen.
Tom Bombadil schrieb:> p.s. Daneben habe ich mir gerade diese Woche eine Bastel-5579 sowie> diverse verschiedene Adapter für die Winterzeit bestellt - Informationen> über laufende Projekte, neue getestete Adapter, neue Implementierungen> usw. dann wie gewohnt ebenfalls im Wiki unter
Wo hast Du denn die 5579 gefunden? Ich habe da nur Dinge in der
Grössenordnung 600 EUR im Netz gesehen. Das ist dann bestimmt nicht was
nur zum Spielen, oder?
Peter B. schrieb:>> ich habe meinen 5573-1 von 2.52 auf 2.61 gehoben. Seitdem kann ich mit> der App „Trovis 55Pro“ für den WW-Kreis die Betriebs-Modi nicht mehr> ändern.> Vorher konnte ich zB von Auto auf Nacht schalten; es wurde dann auf der> HP des Reglers das GLT-Symbol angezeigt und der Modus umgeschaltet.> Jetzt wird merkwürdigerweise nur noch das GLT gesetzt.> Auf dem Rk1 funktioniert alles wie gewohnt???
Hier sollte ich noch ergänzen dass ich auf den Regler via SamHomeGateway
zugreife. Das sollte bzgl meines Problems aber nicht relevant sein.
Hat denn jeman den 5573-1 mit Firmware 2.61 im Einsatz und kann die WW
Betriebsmodus ändern?
Peter B. schrieb:> Sebastian schrieb:>> Du kannst ja Downgraden. Ich hab zwar die 2.61 aber keine WW darüber.>> Das das geht war mir neu. Gleich mal testen …
Downgrade hat funktioniert. Aber geändert hat’s nichts.
Man sieht im Ereignisprotokoll des Regler das HR40112 auf 5 gesetzt
wird. Aber er macht’s nicht. Nur auf der 1. Seite des Reglers wird GLT
angezeigt. Sehr merkwürdig.
Hast du alte Settings? Und mal verglichen ob dort Werte verändert
wurden.
Im Handbuch steht ja was von Werkseinstellungen in gewissen Teilen, die
gesetzt werden, wenn ein FW update stattfindet. Eventuell fehlt hier
eine Sensor Zuordnung?
Wenn du eine alte noch hast, diese laden und auf dem Root ein export als
xml durchführen und dann die aktuellen Werte auslesen und ebenfals ein
export durchführen. Diese dann per hand oder diff mal vergleichen. Oder
im GUI Visuell links/rechts gucken.
Im Handbetrieb sollte der Regler ja sonst auch fahren, funzt das denn ?
@Sebastian
Ja, hab noch eine alte 2.51 config. Hab sie mit der aktuellen im Regler
verglichen -> kein Unterschied. Und auch zurückgeschrieben -> kein
Unterschied.
Ich hab auch mal den Samson Support kontaktiert ... mal sehn.
Ich hab keine Ideen mehr.
@Tom Bombadil
Einfach mit dem Regler-Rad ein paar screens nach rechts gehen.
Geschrieben wird das vom Regler selbst. (see pic)
Hallo Peter,
danke - ich wusste bis eben nicht mal, dass die 5573 solche Gimmicks
hat. ;)
Hatte bisher nur die 5575 und 5576 in der Hand (und heute Abend
hoffentlich endlich meine neue 5579). Die haben sowas nicht ...
/tom
Markus schrieb:> Tom Bombadil schrieb:> ......> Wo hast Du denn die 5579 gefunden? Ich habe da nur Dinge in der> Grössenordnung 600 EUR im Netz gesehen. Das ist dann bestimmt nicht was> nur zum Spielen, oder?
Haha, die hat er mir vermutlich vor der Nase von Ebay (war mit ca160€)
geschnappt, weil ich zuerst klären wollte ob der ins Ausland versendet
.....
Regler 5579
Welche alternativen Lösungen gibt es um von 2 Geräten auszulesen?
Habe jetzt endlich nach gefühlten 50 x lesen die RS232 zum laufen
bekommen. Da dort aber bereits mein Fernwärme-Lieferant hängt brauche
ich eine andere Möglichkeit. Kann am Gerätebus trotzdem gelesen werden?
Gruß
Simon
Hallo Simon,
jup, exakt die bei eBay war es. Hängt jetzt aber blöderweise schon seit
Tagen bei Hermes im Zentrallager und geht nicht weiter. :(
Mehrere Geräte:
Hängt wohl davon ab, was da angeschlossen ist. Oft ist es RS485, da geht
auch sowas hier (Bus), und die RS232 Pins sind frei:
https://www.samsongroup.com/document/t54090de.pdf#page=7. Falls es RS485
2-Draht ist, könnte man den sogar auf die internen Klemmen legen, dann
wäre die Buchse wieder frei.
Ist nur der Zählerbus für Fernauslesung an den M-Bus angebunden, ist
RS232 ebenfalls frei und wäre aufschaltbar.
Sind aber statt dessen die RS232-Pins belegt, ist's vermutlich Essig, da
RS232 eine Punkt-zu-Punkt Verbindung ist. Mehrpunkt fällt sehr
wahrscheinlich aus (nie probiert).
In der Praxis würde ich von sowas aber die Finger lassen - besonders,
wenn Du keine Infos über die Aufschaltung hast. Das kann sonst schnell
teuer werden ...
/tom
@Sebastian
Ich glaub den Fehler gefunden zu haben. Wenn ich den WW-Kreis am Regler
auf Auto schalte reagiert der Regler auf meine Kommandos.
Steht er am Regler auf irgendwas anderes als Auto, kann ich den Kreis
von außen nicht beeinflussen.
Ich meine dass das früher nicht so war. Vielleicht täusche ich mich
auch.
Ist das ein normales Verhalten?
Ich meine bei meiner 5579 war das auch schon immer so. Aber gut zu
wissen, dass das Problem damit behoben ist. Vielleicht wage ich mich
dann auch mal an ein Software Update. Wobei... never change a running
system. :-)
Peter B. schrieb:> @Sebastian>> Ich glaub den Fehler gefunden zu haben. Wenn ich den WW-Kreis am Regler> auf Auto schalte reagiert der Regler auf meine Kommandos.> Steht er am Regler auf irgendwas anderes als Auto, kann ich den Kreis> von außen nicht beeinflussen.> Ich meine dass das früher nicht so war. Vielleicht täusche ich mich> auch.> Ist das ein normales Verhalten?
Durchaus möglich.
Normal sollte jegliche Stellung außer der Handbetrieb die Funktionsweise
im selben Modi fahren. Würde hier dann Fehler auf der Seite Samson
sehen.
Ansonsten ist der Auto Betrieb schlicht die Aktivierung nach
Zeitplan/Sensoren oder halt GLT.
Eventuell hat Tom noch eine andere Begründung.
Hi Tom,
den CO06 -> F20 habe ich auch gesehen. Den gabs aber auch in der 2.51
schon. Daher ist er kein Kandidat für dieses Verhalten.
Ich werde das aber mal bei Samson anfragen.
Ciao
Wo wir hier bei Regler Einstellungen sind.
Frage an alle. Die Tag soll und Nacht soll Temperaturen haben die bei
einer Außenfühler geführten Anlage Einfluss auf die Berechnung der
Heizkurve?
Ja - je nach Einstellungen sogar mehr als Steigung und Niveau, da der
Fußpunkt massiv verschoben wird.
Hat lange gedauert, bis ich das raushatte, da nirgendwo dokumentiert.
Das Bild verdeutlicht das Prinzip, ist aber von einem anderen Regler -
die Funktion für die konkrete Berechnung auf der Trovis hab ich trotz
mehreren Jahren in der Datenbank noch nicht raus.
/tom
p.s. Irgendwie bin ich zu doof, hier Bilder einzufügen, daher:
http://kramkiste.net/pics/einfluss_raumtemperatur.png
Hoch interessant. Hätte ja gedacht dass das obsolet ist ohne raumsensor.
Hatte mal eine Formel notiert(weiß nicht mehr woher)
„vlTp = raumsollT + niveau + (raumsollT - außenT)^0,8281902“
Da ich bis dato dachte, dass das raumsoll trivial ist hab ich das nicht
weiter verfolgt.
Dann werd ich den Ansatz noch mal verfolgen.
Gestern war jemand von den Stadtwerke da, der festgestellt hatte dass
das Überdruckventil (oder so) Einwenig überempfindlich reagiert und
damit ein durchfluss teils nur noch mit 50l statt 305l zu gelassen hat.
Also bei mir im Haus wird's kühler, wenn ich den Raumsoll nach unten
verstelle - auch ohne Raumfühler.
Hier mal was zum Ausprobieren (Shift = 0, Y-Achsenabschnitt = 0, dann
mit der Steigung spielen - der Nullpunkt der Vorlauftemperatur
(f(x)-Achse) macht mehr oder weniger große Sprünge bei Veränderung auf
der Achse um nur 1K, je nach Achsenneigung. Und diese Neigung ist für
die Trovis meines Wissens nicht dokumentiert):
https://www.viteach.de/lineare-funktionen/horizontale-verschiebung-einer-linearen-funktion
Bei dem ganzen Thema "Trovis Heizkurve" bin ich nie zu Ende gekommen.
Hab dafür sogar zum Herumspielen vor Ewigkeiten mal eine Exceltabelle
auf Basis der Heizkurvenformel für eine Vitotronic 200 erstellt, die
drüben im HTD in einer längeren Diskussion geposted wurde (zum
Herumspielen die 4 Werte über dem Diagramm verändern):
https://kramkiste.net/downloads/Heizkurve.xlsx
Einen alternativen Ansatz der Berechnung findet man z.B. hier:
https://community.symcon.de/t/heizkennlinie-berechnen/19788/17
Die Heizkurve ist ja auch nur die eine Seite. Das Regelverhalten und die
Regelgüte spielen da auch noch rein - Dinge wie verzögerte
Temperaturanpassung, maximale Regelabweichung, PID-Einstellungen (Kp, TN
...), Optimierung / Adaption usw wirken sich am Ende auch auf die
effektiv anliegende Vorlauftemperatur aus.
Und am Ende hämmern dann oft noch RTR's mit ihrem ganz eigenen
Regelverhalten dazwischen.
Das alles ist auch der Grund, warum ich mittlerweile aus den
Datenbankwerten mehrerer Jahre Temperaturpaare anhand ihrer Häufungen
gebildet habe, und daraus eine Heizkurve für meine Einstellungen
ableite. Aber selbst die liegt oft genug daneben ...
Um mal mit Theodor Fontane (Effi Briest) zu sprechen: "Es ist ein weites
Feld!"
/tom
Das schreibt Trovis zum Thema "Betriebsmodus per Modbus ändern":
„Die Betriebsmodi lassen und ließen sich auch bisher nur per Modbus
ändern, wenn sich der betreffende Regelkreis am Regler im Auto-Modus
befindet."
@Tom
Und bzgl. CO6 -> F20 schreiben sie:
"Mit CO6->F20-1 kann die GLT-Anzeige vor Ort unterdrückt werden, wenn
die Regler in einem Versorgungsgebiet bspw. den Außentemperaturmesswert
oder einen Pufferspeicher-Sollwert per Modbus zugewiesen bekommen und
das den „Normalzustand“ darstellt.
Die GLT-Anzeige wäre dann, weil es eben der Normalzustand ist, fehl am
Platz…“
Danke für die Info, Peter - macht Sinn.
Anekdote am Rande: Meine Bastel-5579 ist heute angekommen. Sie ist
handschriftlich mit "Schrödinger 81" beschriftet (vermutlich Name des
Vorbesitzers). Es ist zwar keine Katze, aber ich frage mich gerade
ernsthaft, ob ich sie wirklich anschließen soll. ;)
/tom
Tom Bombadil schrieb:> Danke für die Info, Peter - macht Sinn.>> Anekdote am Rande: Meine Bastel-5579 ist heute angekommen. Sie ist> handschriftlich mit "Schrödinger 81" beschriftet (vermutlich Name des> Vorbesitzers). Es ist zwar keine Katze, aber ich frage mich gerade> ernsthaft, ob ich sie wirklich anschließen soll. ;)>> /tom
Wäre super wenn du die Frontschnnitstelle der 5579 mit so einem
Billigteil
zum laufen krigst.
Simon
Glück gehabt - Schrödinger (so heißt das Ding jetzt) läuft, ist
zurückgesetzt, mit Dummy-Sensoren bestückt und parametriert.
Der neue USR-K7, der einen eingebauten TCP/RTU-Konverter hat, ist
ebenfalls fertig belötet und läuft (z.Z. noch mit Hilfsspannung, die
Spannungsregler 5V -> 3V3 sind heute erst angekommen).
Krieg ich den K7 vollständig zum Laufen, kann man sich das ganze
socat-/mbusd-Gedaddel sparen und hat 8 gleichzeitige Zugriffe, wahlweise
als TCP-Gateway oder RTU Client.
Allerdings reden Trovis und K7 noch nicht miteinander - ich bleib dran,
'Jugend forscht', und der Winter ist lang ... ;)
/tom
Update: K7 und Schrödinger kommunizieren jetzt.
55Pro auf dem iPhone gestartet, mit der K7-IP verbunden, ausgelesen -
tut.
TrovisView in einer VM gestartet, per ModbusTCP verbunden - tut.
Firmware-Updater gestartet - tut NICHT, trotz mehrfacher Versuche.
Achtung - der K7 ist genial, aber eigentlich ein Embedded-Modul zum
Aufbringen auf Platinen und hat kein Standard-Rastermaß (2 statt 2.5mm).
Wer damit experimentieren will, sollte ein paar Löt- und
Elektronikkenntnisse haben. Anleitung folgt wie immer, aber erst später.
/tom
Bekommt ihr beim Auslesen auch sporadisch extreme Werte, die nicht
plausibel sind?
Ich lese minütlich ein paar Register aus. Es ist kein Muster zu
erkennen, aber es kann nicht sein, dass es erst eine Außentemperatur von
7°C ist, dann 0,4°C und dann wieder 7,2°C.
Ich hab schon mehrfach alles nochmal sauber zusammengelötet. Mein ESP-01
bekommt Strom von einer externen Quelle und ist lediglich via TX/RX und
GND mit der Trovis verbunden. Leitungslänge ist ca. 30cm.
Nur der Außensensor, oder die anderen auch? Falls nur der, würde ich mal
einen neuen Außensensor bestücken.
Spikes hatte ich hier nur, wenn der Fehler vor dem Bildschirm gesessen
hat.
Ein Nachbar berichtete über eine defekten Rücklaufsensor, der quasi zu
Ausfall seiner Heizung geführt hat, weil in unregelmäßigen Abständen
Temperaturen direkt aus der Hölle gemeldet wurden:
RL>65°C somit RL>RLmax somit Stellventil auf 'zu', weil zu hoher RL =
keine Wärme.
Nach Sensortausch war alles wieder gut.
/tom
Sämtliche Werte tanzen immer wieder aus der Reihe. Aber nur beim
Auslesen via ModBus. Der Fehler muss irgendwo hier bei der übertragung
sein. Mit USB/TTL Adapter und Windows VM klappt alles auf Anhieb via
TrovisView. Ich vermute meinen Fehler daher beim ESP.
Auch seltsam ist, dass via Tasmota und Smart Meter Interface quasi alle
200ms die Modbus Register abgefragt werden (da hab ich an Jens' Skript
gehalten, Danke dafür). Aber irgendwie nur ganz sporadisch mal eine
Antwort kommt. Bei meinem ESP 12 klappt sogar nur die allererste Abfrage
und danach kommt gar keine Antwort mehr). Bei meinem ESP-01 kommt
wenigstens noch ab und zu eine Antwort, wenn auch manchmal totaler
Schrott.
Wie ist denn so die Erfahrung mit der Abtastrate bei Modbus? Wie oft
kann/sollte man denn die Trovis so zu spammen mit Anfragen?
PS: Grüße aus Potsdam, du kommst ja offensichtlich auch aus der Stadt ;)
Die Kommunikationsprobleme lagen bei mir oft im verwendeten
Developmentboard. Habe ich 5573-TX mit ESP-RX direkt verbunden (also
nicht durchs Board geschliffen) waren sie verschwunden.
Mein EnergyESP (Tasmota) hämmert die 5573 im Sekundentakt an, damit ich
im WebUI schön aktuelle Werte sehe. Über die TelePeriod legt man dann
fest, wie oft der Wert per MQTT rausgeht, also z.B. mit Home Assistant
geloggt wird.
Ich polle hier im Minutentakt aus einer Debian-VM auf dem QNAP-NAS
massig Register (bis ca. 200 - je nachdem, an welchem Thema ich grad
dran bin). Ein kompletter Rundlauf dauert 4 .. 6 Sekunden. Minutentakt
reicht mir, eine Heizung ist naturgemäß kein D-Zug. ;)
/tom
Danke dir.
Mein Problem mit dem Auslesen, war übrigens irgendwo in der
Spannungsversorgung oder dem Masseanschluss.
Jetzt lüppt alles Wunderbar. Ich bin auch wieder weggegangen von meiner
ursprünglichen 230V Spannungsversorgung auf 5V (via altem
Handyladegerät) und dann auf 3V (via LM317 und 2 Widerständen).
Ich nutzte jetzt die 5V von der Trovis 5573 (braun/weiß) gehe damit auf
einen 2 poligen ON/OFF Schalter und auf den LM317. Mit 2 Widerständen
regel ich dann die ~5V auf 3V runter ("LM317-Rechner" googlen) für einen
ESP 12F (ich weiß, der ESP will 3,3 V, aber offensichtlich begnügt er
sich auch mit 3V).
Auf dem ESP läuft Tasmota 12.2.0 und dank der 4MB Flash vom ESP 12F, hab
ich 1MB platz für Firmware, 1MB für OTA-Updates und 2MB fürs UFS
(Universal File System).
Kompiliert hab ich Tasmota mit USE_MODBUS_BRIDGE, USE_MODBUS_BRIDGE_TCP,
USE_SCRIPT und den erwähnten 4MB Flash-Size.
Anfangs hab ich im Tasmota Script per SMI (Smart Meter Interface) die
Register ausgelesen, dabei fehlte mir aber die Möglichkeit auch Register
zu schreiben.
Nun nutze ich ausschließlich die ModBus TCP Bridge, welche ich per
Script im Tasmota starte:
```
>D>B
=>Backlog ModBusBaudrate 19200; ModBusSerialConfig 3; ModBusTCPStart
5021
```
Vom HomeAssistant kann ich jetzt via ModBus Integration auf die Register
zugreifen und lesen:
```
modbus:
- name: "trovis"
type: "tcp"
host: 192.168.0.218
port: 5021
retry_on_empty: true
retries: 5
sensors:
- name: "Außentemperaturfühler"
unique_id: "trovis_temperature_outdoor"
input_type: "holding"
slave: 10
address: 9
data_type: int16
scale: 0.1
precision: 1
unit_of_measurement: "°C"
state_class: "measurement"
lazy_error_count: 5
```
Per Dienst klappt auch das zurückschreiben. Zuerst die Schlüsselzahl
(default 1732) in Register 144 und dann die gewünschten Werte:
```
service: modbus.write_register
data:
slave: 10
address: 144
value: 1732
hub: trovis
```
Z.B. Betriebsmodus Sonne für RK1
```
service: modbus.write_register
data:
slave: 10
address: 105
value: 4
hub: trovis
```
An der Trovis wechselt dann im Infobildschirm, wo normalerweise nur die
Uhrzeit steht, der Text GLT (GebäudeLeitTechnik) und die Uhrzeit.
Einziges Manko: Beim Anschalten meines ESP (durch o.g. Schalter) startet
die Trovis mit einem Fehlercode neu. Ich vermute, dass es irgendwas mit
dem Anlaufstrom zu tun hat.
Das ganze läuft jetzt 8h konstant. Mal schauen, wie es weiter geht.
Danke euch. Ganz besonders Tom & Jens (Tasmota)
Kurze Rück-/Erfolgsmeldung:
Eine Woche lang lief hier ein USR-K7 im seriellen Modus über das alte
Verfahren, wie es im Wiki beschrieben ist (seriell/rtu über socat- bzw.
mbusd).
Im Laufe der Woche habe ich in mein Plugin ModbusTCP implementiert - es
kann jetzt wahlweise beide Verfahren (rtu und tcp), und berücksichtigt
auch die heftigen Umstellungen in pymodbus 3.0+.
Seit 24h läuft der K7 jetzt über ModbusTCP, bei gleichzeitigem Zugriff
per Plugin und 55Pro vom Handy (bis zu 8 gleichzeitige Zugriffe kann der
Adapter verarbeiten). Spannungsversorgung über die Trovis per 5V->3.3V
Step-Down-Regler. Das Fehlerlog ist komplett leer, der K7 läuft stabil
seit >24h, kein Reset zwischendurch.
Im Klartext: Der Umweg über socat oder mbusd ist zukünftig nicht mehr
erforderlich, beide werden nicht mehr benötigt. Weiterhin kann jeder
moderne Standard-TCP-Modbusclient die Trovis jetzt auslesen. Das dürfte
die Anwendungsfälle massiv erweitern.
Ich warte jetzt noch auf einen anderen Adapter, der auf dem Weg ist, und
der leichter als der K7 in Betrieb zu nehmen ist und 'nativ' 5V kann
(den K7 empfehle ich nur bei guten Elektronik- und Lötkenntnissen - 2x
K7 hat es auf meinem Weg hierher geerdet, die werde ich erst im nächsten
Leben wiedersehen).
Sobald der Adapter da und in Betrieb ist, kommt die ausführliche
Anleitung im Wiki (inkl. Verweise auf den K7, falls den doch jemand
anstöpseln möchte - das Ding ist SUPER klein, niedlich und schnell, ich
mag ihn einfach).
/tom
p.s. Eine 5576-0003 v. 2.21 ist bei eBay online, falls es wen
interessiert - vom selben Verkäufer wie meine Bastel-5579.
Ich habe die Anleitung
https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki
für meine Trovis 5573 0001 genau befolgt, um die Verbindung herzustellen
und mit Trovis-View den Regler auszulesen/ zu beschreiben. Und siehe
da, es funktioniert. Dabei habe ich auch den USRIOT (USR TCP-232-T2)
genutzt.
Meine Erfahrung: Es hat lange gedauert, da ich einen Fehler hatte: Mein
Kabel, welches ich als Verbinding von der Trovis zum USR TCP-232-T2
genutzt habe, war 70 cm lang (damit es bei mir gut an die Wand passt).
Das funktionierte nicht. Insbesondere Trovis View hat mir
Fehlermeldungen gegeben: Wahlweise Com Port konnte nicht geöffnet
werden, oder eine Time-Out Meldung. Schließlich habe ich es gekürzt und
siehe da, es klappt.
Nächster Schritt ist das Data Logging mit Openhab 3 über den Raspberry.
Hat jemand hierzu ein Rezept parat?
Rezept nicht, aber:
Unter https://www.openhab.org/addons/bindings/modbus/ wird auch RTU
(seriell) als unterstützt gemeldet. Wenn ich openHAB richtig verstehe,
muss man für das 'Binding' (Modbus) eine 'Extension' (Trovis) erstellen
(Register-Nummern, Coils usw).
Ich bin der Überzeugung, ich hätte genau so eine Extension schon mal
irgendwo bei meinen Recherchen gesehen, aber finde die nicht mehr (hab
das auch heute schon bei meinen Wiki-Updates als 'lost' aufgenommen).
Falls Du planst, sowas selbst zu erstellen: Warte bitte noch ein paar
Tage - gerade dieses Wochenende habe ich die Coils- und Registertabellen
im Wiki aktualisiert (u.a. die 40.000er Adressen als extra Feld
aufgenommen), und durch die neue TCP-Anbindung (noch zu dokumentieren)
entfällt der Umweg über die serielle Schnittstelle (erfordert ggf. neuen
Adapter, aber Du hast einen 'Point of potential Failure' weniger, was es
deutlich einfacher macht).
/tom
@ Tom
Du hast ja python scripts zum Auslesen erstellt. Kann ich diese einfach
auf meinem raspi via cron laufen lassen und die Trovis auslesen? Dann
kann ich die gewünschten Daten einfach via mqtt nach OH3 liefern.
Vermutlich das Script _init_.py
Mit welchem Befehl müsste ich es aufrufen?
Ehrlich gesagt - keine Ahnung. Ich hab die _init_.py nie solo
ausgeführt, sondern immer als Plugin für smarthomeNG verwendet, welches
sich um Aufruf, Scheduler usw kümmert.
Die Funktionen sollten sich aber definitiv als Basis für was eigenes
nutzen lassen, die Sniffer im Tools-Verzeichnis des Plugins laufen ja
auch eigenständig ...
/tom
Oder nen ESP-01 für 2€ bestellen und Tasmota+SMI flashen. Billigste
MQTT-Gateway mit dem geringsten Stromverbrauch, dass man sich vorstellen
kann. Aber hab ich ja oft genug erwähnt.
Sebastian schrieb:> Wo wir hier bei Regler Einstellungen sind.>> Frage an alle. Die Tag soll und Nacht soll Temperaturen haben die bei> einer Außenfühler geführten Anlage Einfluss auf die Berechnung der> Heizkurve?
Folgende Info hat mir Samson gegeben:
Die Einstellungen am Drehschalter Heizkreis haben folgende Formeln:
Sollwert Tag
Vorlauf-Sollwertänderung = 2 x Heizkennliniensteigung x (Tagsollwert_1 –
Tagsollwert_2)
Beispiel: wird bei einem Heizkreis mit Steigung 1,2 der Tagsollwert von
20°C auf 22°C erhöht,
erhöht sich der Vorlaufsollwert um 4,8 °C
Sollwert Nacht
Die Nachtabsenkung kann bei Sollwert Nacht eingestellt werden und hat
folgende Formel:
Nachtabsenkung = 2 x Heizkennliniensteigung x (Raumsollwert Tag –
Raumsollwert Nacht)
Beispiel: bei einer Steigung 1,2 und Raumsollwert Tag 20°C und
Raumsollwert Nacht 15°C,
wird in der Nacht um 12°C abgesenkt
Peter B. schrieb:> Vorlauf-Sollwertänderung = 2 x Heizkennliniensteigung x (Tagsollwert_1 –> Tagsollwert_2)> [...]> Nachtabsenkung = 2 x Heizkennliniensteigung x (Raumsollwert Tag –> Raumsollwert Nacht)
Danke, Peter. Interessant - das würde bedeuten, dass bei Steigung = 0
(Werkseinstellung) TagSOLL und NachtSOLL wirkungslos sind, oder?
Haben die sich auch zur Heizkurve selbst geäußert? Die bleibt nach wie
vor ein Rätsel - ich komm nur näherungsweise ran, egal welche Formel ich
nehme. Und schon am nächsten Tag sitzt der Soll-VL schon wieder an
unerwarteter Stelle ...
/tom
Hi Tom,
Steigung=0? Du sprichst schon von der Heizkennlinie? Nur macht da 0
keinen Sinn und ist auch nicht Standard.
Bzgl. einer Formel für die Heizkennlinie habe ich nicht nachgefragt. Ich
schau mal bei Gelegenheit. Könnte mir vorstellen dass sie dies nicht so
gern rausgeben.
Peter B. schrieb:> Steigung=0? Du sprichst schon von der Heizkennlinie? Nur macht da 0> keinen Sinn und ist auch nicht Standard.
Hallo Peter,
hast natürlich Recht - ich war gedanklich beim Niveau, nicht bei der
Steigung. Letztere geht ja gar nicht <0,2.
/tom
Peter B. schrieb:> Bzgl. einer Formel für die Heizkennlinie habe ich nicht nachgefragt.> Ich schau mal bei Gelegenheit. Könnte mir vorstellen dass sie dies> nicht so gern rausgeben.
Dazu gibt es seit gestern Abend interessante Neuigkeiten:
https://www.haustechnikdialog.de/Forum/p/3447779
:)
/tom
Hallo zusammen,
ich lese meine 5573-0003 über einen TCP Adapter (USR-TCP232-E2) aus.
Dazu verwende ich im iobroker den modbus adapter. Die Registeradressen
habe ich aus dieser Liste übernommen:
https://github.com/Tom-Bom-badil/samson_trovis_557x/blob/master/templates/5576-003_registers.py
Folgende Fragen habe ich:
- Sind das alles "Eingangsregister"? (Also keine Holding Register?)
- Wo finde ich das Datenformat der einzelnen Register (also z.B.
"Unsigned 16 bit (Big Endian)" oder "Signed 16 bit (Little Endian)"
etc.?
Z.B. die Adresse 9 "AussentempAF1": Da ist als Umrechnungsfaktor in der
oben genannten Datei (5576-003_registers.py) nur 0.1 angegeben und kein
Offset. Da der Minwert -400 ist muss es ja irgendwie ein Signed Register
sein oder?
Egal was ich einstelle, ich bekomme keine sinnvollen Werte angezeigt...
Würde mich freuen wenn jemand was weiß :)
Hallo,
vielen Dank erstmal für die vielen hilfreichen Beiträge!
Ich habe meine Wärmeübergabestation (Trovis 5573-10, SW-Vers: 2.41,
Anlage 2.1 ohne Raumsensor) per Modbus eingebunden und mir ist
aufgefallen, dass die FBH-Pumpe fast durchgehend läuft, obwohl meine
Raumthermostate fast immer geschlossen sind. Der Heizbedarf (Steigung
schon auf 0,2) ist äußerst gering und ich würde die Heizung gerne nur
bei Bedarf einschalten.
Ist es möglich den Raumsensorwert per Modbus zu beschreiben und über
Kurzzeitadaption den Heizbetrieb abzuschalten oder seht Ihr andere
Möglichkeiten?
@Carl - Die Übertragung erfolgt als Big Endian, das kannst Du in der
Konsole des E2 sehen. Die Endianess hat doch aber nichts mit
signed/unsigned zu tun!? Sie gibt doch nur die Reihenfolge von
High-/Lowbyte an?
Weitere Detailinfos zu Trovis + Endian/LSB/MSB hier:
https://github.com/arendst/Tasmota/issues/9586#issuecomment-1221270120
Anhand der Informationen aus der Registerliste musst Du die Daten ggf.
aufbereiten - ist min<0, dann muss es logischerweise signed sein. Auszug
aus meinem Plugin:
1
# 16bit-Register auf negativen Wert prüfen (z.B. Temperaturen)
2
if busmin < 0 and buswert > 32767:
3
signed_int = buswert - 65536
4
else:
5
signed_int = buswert
Die Registerliste ist naturgemäß ein Mix aus Input und Holding Registers
bzw. Coils und Discrete Inputs. Was was ist, ergibt sich daraus, ob es
read-only oder read-write ist (steht an jedem Register / Coil dran).
@Klaus: Ja, einen Raumsensorwert in die Trovis zu schreiben wurde
kürzlich im Modbus-KNX-Projekt gemacht. Es funktioniert gut - der Regler
reagiert genau wie erwartet. Link siehe Wiki.
Mit der Adaption kenne ich mich aber leider nicht aus, meine Pumpe läuft
ebenfalls 24/7 auf Proportionaldruck, der regelt auch die
Leistungsaufnahme.
/tom
Danke für die Infos. Die Info mit dem Offset hatte ich gesucht (-65536)
und auch die Info mit den Holding Registern hilft weiter.
(Und ja, Endianess und signed/unsigned hat nichts miteinander zu tun)
Leider komme ich gerade trotzdem nicht weiter, da ich ein seltsames
Verhalten habe.
Die ausgelesenen Werte betragen immer den Wert "Registeradresse * 256",
für Register 9 (AussentempAF1) bekomme ich also "2304". Eine Verbindung
zwischen dem USR-TCP232-E2 und der 5573-0003 scheine ich aber zu haben,
da sobald ich das Rx oder Tx Kabel unterbreche ich auch kein Update der
Werte mehr bekomme....
Carl schrieb:> Eine Verbindung zwischen dem USR-TCP232-E2 und der 5573-0003> scheine ich aber zu haben, da sobald ich das Rx oder Tx Kabel> unterbreche ich auch kein Update der Werte mehr bekomme....
Wenn Du auf die Weboberfläche des E2 gehst, kannst Du die Kommunikation
im Menü "Web to Serial" live verfolgen und die Datenpakete sehen.
Kommst Du mit TrovisView auf die Trovis? Sollte ja gehen, wenn die
Verbindung steht ...
/tom
Danke für die Infos. Ich sehe im "Web to Serial" tatsächlich nur meine
gesendeten Kommandos, keine Empfangenen :(
Die richtigen Pins scheine ich aber verbunden zu haben, denn ich sehe
auch die gesendeten Kommandos nur dann wenn ich Pin 1 und 8 richtig
herum verbunden habe.
Also scheint die Steuerung entweder die Befehle nicht zu verstehen oder
sie antwortet nicht...(oder irgendwas stimmt mit den Spannungspegeln
nicht?!(Ich versorge meinen E2 mit VDD -> 5V))
Hier meine Einstellungen der Trovis (5573-0003 FW 2.48)
PA6: 247 (Stationsadresse)
CO6-F01: 1 (Modbus aktiv)
C06-F02: 0 (8 Bit Adressierung) (Habe aber auch schon mit "1" 16-Bt
Adressierung probiert)
C06-F03: 0 (Modemfunktion) (Habe auch schon 1 probiert)
C06-F04: 0 (Auto. Modemkonfig) (Habe auch schon 0 probiert, wenn F03 =
1)
Testbefehl: 0xf7 0x3 0x0 0x9 0x0 0x1 0x40 0x9e
(Auslesen Register 9. Bei den letzten 2 Bytes (CRC) bin ich mir nicht
ganz sicher)
Keine Ahnung was ich noch ausprobieren soll...Bin weiterhin für gute
Ideen und Rückfragen offen :)
(Trovis View habe ich noch nicht ausprobiert. Müsste ich unter Wine
installieren. Aber kann ich mich mit einem E2 (also über LAN) mit Trovis
View auf die 5573 verbinden? Oder brauch ich dann irgendwelche Adapter)
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang