Announcement: there is an English version of this forum on 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]
:
Bearbeitet durch User
> 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.
Angehängte Dateien:
-
Bildschirmfoto_2022-09-20_um_18.49.44.png
37 KB -
IMG_7610.jpg
230 KB
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]
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
20220921_Trendviewer.jpg
340 KB
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 zusammen, habe mal eine Frage zum Auslesen per minimalmodbus. Bei der read_register-Methode
1 | print(instrument.read_register(0, 0)) |
ist der erste Parameter die Registeraddresse, welche in Dezimal angegeben werden muss. Die Registeradressen für meine 5573 hole ich mir von hier: [98_ModbusTrovis5576.pm|https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/98_ModbusTrovis5576.pm] 1. Aus 'h9' wird dann 9.
1 | print(instrument.read_register(9, 1)) |
Aber was mach ich mit den Werten, die mit c beginnen? 2. Sind die Register-Werte für die 5576 auch für die 5573 verwendbar. Danke Martin
Dies sind keine Register sondern "Coils". Leider kann ich Dir aber nicht mehr dazu sagen. Vlt. gibt es eine entsprechende Funktion für coils?
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] |
# functionscode default 3 => https://minimalmodbus.readthedocs.io/en/stable/modbusdetails.html?highlight=function%20#modbus-implementation-details 3= holding register du benötigst aber 1 Read bits (coils) die du nach der doku her nicht übergeben kannst im aufruf ( probieren kannst es ja trotzdem) denke du wirst du auf read_bit() funktion zurückgreifen müssen
:
Bearbeitet durch User
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?
Du kannst ja Downgraden. Ich hab zwar die 2.61 aber keine WW darüber.
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 …
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 ?
> Ereignisprotokoll
Welches Ereignisprotokoll, und von welcher Seite wird das geschrieben?
/tom
Angehängte Dateien:
-
IMG_7981.jpg
230 KB
@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.
Hallo Peter, erscheint mir plausibel wie von Dir beschrieben. Nur so als Gedanke: Könnte das vielleicht was mit dem Hinweis hier zu tun haben? Über die Funktion bin ich erst kürzlich gestolpert - zumindest bin ich mir nicht bewusst, dass es das in den alten Firmwares schon gab (oder ich hab's schlicht früher immer überlesen, lief ja alles ;)). https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki/Weiterf%C3%BChrende-Informationen#schreiben-von-registerncoils https://www.samsongroup.com/document/e55760de.pdf#page=228 /tom
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?
Angehängte Dateien:
-
einfluss_raumtemperatur.png
200 KB -
einfluss_raumtemperatur.png
200 KB
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
Ich habe mal die wichtigsten Dinge zu ESP, Trovis und noch ein paar Sachen zusammengefasst: https://github.com/TheChatty/SmartESPatMax
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
Mei… vermutlich funktioniert sie und gleichzeitig auch nicht 😂
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
Gibt es eigentlich irgendwo ein Changelog zu den Firmwares von Samson? Eigentlich heißt es doch "never change..."
Ja in der Bedienungsanleitung unter Firmwareversionen. Bei der 5579 bspw. in Kapitel 2.2 https://www.samsongroup.com/document/e55790de.pdf
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)
@Robert: Danke für die interessante Beschreibung, wie einfach das mit HA ist. Definitiv auch ein interessantes Feld.
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.
So, die Anleitung zur Inbetriebnahme eines K7 liegt jetzt vor: https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki/Nachtrag:-Weitere-von-mir-getestete-Adapter#usr-k7 232-E2 folgt als nächstes, der ist einfacher. Falls in der Beschreibung etwas unklar ist oder jemand Fehler findet - gefundene Fehler dürfen nicht behalten und gern an mich zurückgemeldet werden. :) /tom
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.
Angehängte Dateien:
Falls es jemanden interessiert, ich habe meinen Regler per Samson SamHomeGw angebunden.
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
Welche Hardware benötige ich für ein Firmwareupdate einer Trovis 5573?
Beitrag #7314449 wurde von einem Moderator gelöscht.
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)
Es scheint immer wieder die 5573 zu sein, die Zicken macht. Es gibt auch nach wie vor 2 Varianten, wie sie anzukabeln ist - bei manchen die Pins 2/3/6/7, bei anderen wohl 1/2/7/8 (siehe https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki/Modellspezifische-Informationen#5573). Kann das hier leider mangels 5573 nicht verifizieren. Da Du offensichtlich nur Linux/Unix verwendest, findest Du im Wiki entsprechende Kommandos zum Testen der Verbindung mit Bordmitteln hier: https://github.com/Tom-Bom-badil/samson_trovis_557x/wiki/Schritt-5:-Erster-Test-von-Kabel-und-Adapter#unix--linux-mit-bordmitteln Und hier noch die Lösung eines Nutzers, bei dem die 'Wehen' mit seiner 5573 am Anfang auch recht lang waren: https://knx-user-forum.de/forum/supportforen/smarthome-py/1390281-trovis-557x-heizungsregler-plugin?p=1685113#post1685113 Viel Erfolg! /tom
Thread beobachten
Seitenaufteilung abschalten