Skip to content

Aktualisierte Informationen

Tom Bombadil edited this page Oct 23, 2022 · 60 revisions

==================> Seite zur Zeit in Bearbeitung <=========================

[Update #1] [11-2019]

Negative Temperaturen wurden aufgrund eines Programmierfehlers im Plugin als positive Temperaturen gelogged (technisch: unsigned INT war implementiert, aber signed INT war zu verwenden).

Ist in der aktuellen Version des shNG-Plugins gefixed.

[Update #2] [10-2021]

Berichte von 5573-Nutzern: Das für die 5576 entwickelte shNG-Plugin greift teilweise auf Register zu, die es in der 5573 nicht gibt. Eine entsprechende Routine zur Fehlerbehandlung wurde eingefügt, so dass die Logfiles jetzt keine solchen Fehlermeldungen mehr aufweisen und ungültige Bereichsangaben nicht mehr zum Abbruch der Ausleseschleife führt. Eine manuelle Anpassung der Register- und Coils-Listen ist damit nicht mehr notwendig.

[Update #3] [07-2022]

Mittlerweile scheinen die hier hinterlegten Register- und Coil-Dateien recht gut herumzukommen. Etliche neue Plugins und Modbus-Adaptionen basieren darauf. Daher hier eine Link-Sammlung auf erfolgreiche Projekte und Info-Sammlungen. Bitte gern anschreiben, falls ein Link fehlt:

... sowie einige weitere, persönliche Projekte.

[Update #4] [10-2022]

Bei einem unregelmäßigen Besuch der Seite von Samson die große Überraschung: Sowohl die Firmware als auch das notwendige Update-Programm stehen jetzt zum Download zur Verfügung!

Ganz großes Kino, Samson - vielen Dank dafür!

In einer Windows7-VM wurde der Regler mittels VCom (COM1:, siehe Anleitung oben) problemlos auf die aktuellste Version 2.61 geflashed. Dauert gefühlt 10 Minuten mit dem üblichen Bauchgefühl bei Firmware-Updates - aber lief auf Anhieb. Nur ein Kaltstart (Sicherung raus, 10s warten, Sicherung rein) wurde nach dem Update von mir gemacht, obwohl nicht zwingend vorgeschrieben ...

[Update #5] [10-2022]

Der User Volker V. (@volki21) im Microcontroller-Forum hat schon vor einiger Zeit herausgefunden, wie sich die hier gepostete Hardwarelösung erweitern lässt, so dass man mittels Trovis View (PC), 55Viewer (Handy) oder beliebigen anderen Modbus-Clients (z.B. Eigenbau) per IP über Netzwerk / WLAN auf die Trovis zugreifen kann. Der ABSOLUTE Hammer!

Danke Volki21 - ich arbeite gerade eine 'allgemeintaugliche' Schritt-für-Schritt Anleitung dafür aus, die die Schnittstelle /dev/trovis wie hier in der Anleitung beschrieben nutzt. Kommt in den nächsten Tagen genau hier ...

===> Alles ab hier bitte ignorieren <===

55Home (Nur Android) https://play.google.com/store/apps/details?id=de.kt_elektronik.home

55Pro (iOS, Android) https://apps.apple.com/de/app/55mobile/id943003351, https://play.google.com/store/apps/details?id=kt.ffMobile,

TrovisView für Trovis 5500-Regler (ganz unten auf der Seite) https://www.samsongroup.com/de/service-support/downloads/trovis-view/

Übersicht der Regler mit Firmwares (https://www.samsongroup.com/de/produkte-anwendungen/produkte/automationssysteme)

Bootmanager zum Afuspielen neuer Firmware (https://www.kt-elektronik.de/n1/software/Bootmanager_V1.62_Setup.zip)


--> Problembehebung simultaner Zugriff einarbeiten

Einige Nutzer berichten über seltsames Verhalten, wenn sie per Handy-App und mbusd auf den Regler zugreifen. Dies kann ich mittlerweile im Netzwerk reproduzieren (USB-Zugriff kann ich mangels Adapter leider nicht mehr testen).

Sofern mbusd auf die Trovis über dieselbe Schnittstelle zugreifen soll, die bereits ein anderer Dienst verwendet (bei mir: Zugriff über /dev/trovis durch mein smarthomeNG-Plugin), scheint es zu Konflikten zu kommen. Die Schnittstelle wird teilweise über Stunden blockiert, wie diese reproduzierbaren Plots einer Speicherladung zeigen:

fehler_mbusd

Mein Plugin liest den Regler schon seit Jahren stabil und zuverlässig im Minutentakt über die mittels socat angelegte Schnittstelle /dev/trovis aus. Sobald zusätzlich mbusd als Dienst gestartet wird und ebenfalls /dev/trovis für die Kommunikation verwendet, ist die Kommunikation gestört.

Beide Plots zeigen die nächtliche Erwärmungen des WW-Speichers von 49.9°C auf 60°C und müssten somit eigentlich gleich sein - im rechten Plot bekommt das Plugin aber offensichtlich über Stunden keine Daten, was zu langen Linien zwischen Datenpunkten führt. Offensichtlich wird der Regler zwischen 4:15 und 6:00 nur 4 mal ausgelesen (eigentlich müssten aber alle 60s Sekunden Daten kommen).

Sobald der mbusd-Dienst gestoppt wird, kann das Plugin wieder alle 60s Daten lesen.

Ob es tatsächlich an mbusd liegt oder am verwendeten RS232-Adapter, kann ich momentan noch nicht sagen. Es könnte durchaus der Adapter sein, denn zwei verschiedene Modbus-Master greifen darauf mit gleicher Absender-IP und gleichem Port zu.

--> Lösung #Beschreibung #ToDo

  • /dev #1 zusätzliche IP
  • /dev #2 zusätzliche Schnittstelle

mbusd Installation

mbusd ist nicht als 'fertiges' Programm verfügbar, sondern nur im Quellcode, der selbst übersetzt werden muss.

Dies geschieht mit folgenden Befehlen:

# Vorbereitungen
cd /usr/local
mkdir mbusd
chmod 755 mbusd
cd mbusd
 
# Holen
git clone https://github.com/3cky/mbusd.git mbusd.git
 
# Erstellen
# alt cmake -DCMAKE_INSTALL_PREFIX=/usr mbusd.git
cmake -DCMAKE_INSTALL_PREFIX=/usr/local mbusd.git
make
sudo make install
 
# Default-config kopieren
cp /etc/mbusd/mbusd.conf.example /etc/mbusd/mbusd-trovis.conf

$$\textcolor{red}{\text{Hello World}}$$ Im Editor die Datei /etc/mbusd/trovis-mbusd.conf wie folgt modifizieren:

#############################################

# #

# Sample configuration file for mbusd #

# #

#############################################

########## Serial port settings #############

> 
> # Serial port device name
> device = /dev/trovis

> > > `> # Serial port speed`
> > > `> speed = 19200`
> > > `> `
> > > `> # Serial port mode`
> > > `> mode = 8n1`
> > > `> `
> > > `> # RS-485 data direction control type (addc, rts, sysfs_0, sysfs_1)`
> > > `> trx_control = addc`
> > > `> `
> > > `> # Sysfs file to use to control data direction`
> > > `> # trx_sysfile =`
> > > `> `
> > > `> ############# TCP port settings #############`
> > > `> `
> > > `> # TCP server address to bind`
> > > `> address = 0.0.0.0`
> > > `> `
> > > `> # TCP server port number`
> > > `> port = 502`
> > > `> `
> > > `> # Maximum number of simultaneous TCP connections`
> > > `> maxconn = 32`
> > > `> `
> > > `> # Connection timeout value in seconds`
> > > `> timeout = 60`
> > > `> `
> > > `> ######### Request/response settings #########`
> > > `> `
> > > `> # Maximum number of request retries`
> > > `> retries = 3`
> > > `> `
> > > `> # Pause between requests in milliseconds`
> > > `> pause = 100`
> > > `> `
> > > `> # Response wait time in milliseconds`
> > > `> wait = 500`
> > > `> `
> > > `> # Reply on Broadcast`
> > > `> replyonbroadcast = no`

cd /etc/systemd/system mv multi-user.target.wants/mbusd@trovis.service default.target.wants/mbusd@trovis.service

--> requires trovis.service einarbeiten

[Unit] Description=Modbus Master for Trovis network access. Requires=network.target After=network-online.target mbusd-trovis.service Wants=network-online.target

[Service] ExecStart=/usr/local/mbusd/mbusd -d -v2 -L - -c /etc/mbusd/mbusd-trovis.conf -p /dev/mbusd-trovis Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal

[Install] WantedBy=multi-user.target


systemctl daemon-reload systemctl enable mbusd@trovis.service

Test:

systemctl start mbusd@trovis.service systemctl status mbusd@trovis.service


Anhang: Info-Sammlung


Clone this wiki locally