Python 3.8 bzw. 3.9.: SmartHomeNG startet nicht

[Cannon]

Ich werde mich dem modbus-Thema noch mal annehmen, wenn ich das Update der SmartHomeNG auf 1.9.3 gemacht habe. Denn vom modbus gibt es auch eine aktualisierte Version. Dann teste ich das und kann noch mal die Abhängigkeiten korrigieren.

Hinweis zur Modbus-Umstellung (der Vollständigkeit halber): Raider heißt jetzt Twix, sonst ändert sich nix.

Die Umstellung bezieht sich auf die modbus 3.x - Version? Wenn ja, wäre evtl. eine Abfrage sinnvoll?

Die try/except Statemants (siehe oben) gefallen mir eigentlich nicht so recht. Kann man nicht direkt die Version prüfen? Modbus 3.0.1 setzt mindestens python 3.8 voraus. Und das hat ja auch nicht jeder. SmartHomeNG braucht ja Minimum nur 3.7.

[Tom Bombadil]

Bei mir ist es sogar noch verrückter - pymodbus alt/neu, modbus rtu/tcp. Je nach Konstellation also 4 Möglichkeiten, und je nach geladenem Modul ist bei den Abfragen unit oder slave zu verwenden.

Zur Version: https://pymodbus.readthedocs.io/en/l...modbus.version

/tom


Edit:

Gerade auf Livesystem (alte Version, Python 3.6) und Entwicklungssystem (gerade frisch geupdated, Python 3.10) probiert:

python3
>>> from pymodbus.version import version
>>> version.short()
'2.4.0'
>>> a=version.short()
>>> a[0]
'2'

python3
>>> from pymodbus.version import version
>>> version.short()
'3.0.2'
>>> a=version.short()
>>> a[0]
'3'
​

Steht vorn eine 2, dann die alte Schreibweise, sonst die neue.

[Cannon]

Steht vorn eine 2, dann die alte Schreibweise, sonst die neue.

Super. Update ist durch und getestet habe ich das auch - zumindest mit der neuen Version. Sieht jetzt im pluggit-Code so aus. Ich habs noch mal angepasst, falls es mal eine Version > 9 geben soll, funktioniert auch das dann:

from pymodbus.version import version
pymodbus_baseversion = int(version.short().split('.')[0])

if pymodbus_baseversion > 2:
    # for newer versions of pymodbus
    from pymodbus.client.tcp import ModbusTcpClient
else:
    # for older versions of pymodbus
    from pymodbus.client.sync import ModbusTcpClient​

[Tom Bombadil]

Ja, ich werd auch grad fertig (glaube ich).

Die Trovis hat einen eingebauten RS232 mit RTU kann jetzt aus dem Plugin per RJ45-Adapter wie folgt angesprochen werden: Seriell (Modbus RTU), USB (Modbus RTU), LAN (Modbus RTU), LAN (Modbus TCP). Natürlich jeweils mit altem und neuem pymodbus. Und wer TCP macht, kann auch die herstellereigenen Handy-Apps sowie die herstellereigenen Konfigurationsprogramme direkt und ohne Umwege mit der Trovis verbinden.

Alter Falter, ist das ein Projekt geworden ...

/tom

[Cannon]

Alter Falter, ist das ein Projekt geworden ... https://knx-user-forum.de/core/image...EAAAICRAEAOw==

Ja, ich habe mir mal in den plugins alles durchsuchen lassen, was noch gefixt werden muss.

• Pluggit habe ich gemacht
• Trovis machst du, bzw. hast du gemacht

Es stehen noch aus für den Import-Fix:

• kostalmodbus
• ksemmodbus
• modbus_tcp
• sma_mb

und für den read_coils-Fix:

• modbus_tcp

Das sollte alles sein, soweit ich das sehe. Da das alles aktuelle Plugins sind, stellt sich die Frage, ob das die Entwickler selbst machen oder soll ich?

[Tom Bombadil]

Helios ist übrigens auch Modbus - aber damals noch mangels Bibliothek das ganze Protokoll 'von Hand' abprogrammiert, daher kein Änderungsbedarf.

/tom

[Morg]

Damit läuft dann das squeezebox-Plugin (sdp_squeezebox). Aber nicht das pluggit-Plugin. Die Fehlermeldung mit "serial_asyncio" kommt dann immernoch.

Mal aus Neugier - woher hast du das sdp_squeezebox-Plugin? Dann hast du auch die sdp-Quellen installiert?

Und ja, sdp braucht "pauschal" pyserial. Man könnte das auch nur "nach Bedarf" importieren, aber wenn mehrere auf sdp basierende Plugins laufen, müsste das jedesmal neu geprüft und abhängig importiert werden. Da schien mir ein "pauschal importieren" einfacher Aber da es noch nicht in develop ist, könnte man das bei entsprechendem Feedback ja noch ändern...

[Cannon]

Mal aus Neugier - woher hast du das sdp_squeezebox-Plugin? Dann hast du auch die sdp-Quellen installiert?

DIe Frage ist mir nicht ganz klar. Das Plugin ist doch von dir. OnkelAndy hatte das empfohlen:

https://knx-user-forum.de/forum/supp...egungen/page13

Helios ist übrigens auch Modbus - aber damals noch mangels Bibliothek das ganze Protokoll 'von Hand' abprogrammiert, daher kein Änderungsbedarf.

Ja, deshalb stehts nicht mit drin in derr Liste.

Wenn das mit github jetzt bei mir läuft, werde ich die anderen Plugins auch mal anpassen.

[Morg]

DIe Frage ist mir nicht ganz klar. Das Plugin ist doch von dir. OnkelAndy hatte das empfohlen:

Ich weiß schon, dass das von mir ist es klang nur im Text so, als wenn du das "normale" Squeezebox-Plugin benutzt, und wenn du es aus "meinem" Repo hast, findest du dazu sicher noch keine Doku in shng Master/develop

Aber fein, wenn es benutzt wird (und funktioniert )

[Onkelandy]

Da können wir uns dann ja glatt bald mal an die endgültige Implementierung des sdp_xx machen, oder ?

[Morg]

Ja, sobald SmartPlugin "live" und ggf. entbuggt ist und wir sdp in develop haben

[Cannon]

Es stehen noch aus für den Import-Fix:

• kostalmodbus
• ksemmodbus
• modbus_tcp
• sma_mb

und für den read_coils-Fix:

• modbus_tcp

Ich habe das jetzt alles gefixt und einen pull-request gestellt. Die requirements habe ich bei allen auch angepasst. Die sehen jetzt wie folgt aus:

pymodbus==2.5.3;python_version<"3.8"
pymodbus>=3.0.2;python_version>="3.8"​

Da ich nur das plugin pluggit testen kann, bitte ich um Feedback bei den anderen Plugins. Vorab gern auch hier, bevor die im Develop drin sind.

[beavon]

Hallo,

ich habe gerade das sma_mb-Plugin auf meinem Testsystem mit SmarthomeNG 1.9.3 getestet und musste die folgende Zeile in der __init__.py anpassen:

client = ModbusTcpClient(self._host, self._port)

Danach läuft es ansonsten bisher ohne Fehler und liefert die erwarteten Werte.
Danke für den Fix!

Gruß
Frank

[Cannon]

ich habe gerade das sma_mb-Plugin auf meinem Testsystem mit SmarthomeNG 1.9.3 getestet und musste die folgende Zeile in der __init__.py anpassen:

Danke für den Hinweis. Mangels Testmöglichkeit, habe ich das "as" im Import übersehen. Ich werde mir die Sachen noch mal anschauen und das ggf. bei den anderen auch fixen.

[Tom Bombadil]

Läuft hier mittlerweile stabil und wahlweise über ModbusRTU oder ModbusTCP:

try:   # rtu/serial, for pymodbus3+ or pymodbus2.x
    from pymodbus.client import ModbusSerialClient
except:
    from pymodbus.client.sync import ModbusSerialClient

try:   # tcp, for pymodbus3+ or pymodbus2.x
    from pymodbus.client.tcp import ModbusTcpClient
except:
    from pymodbus.client.sync import ModbusTcpClient

if self._modbus_mode == 'rtu':
    connection = ModbusSerialClient(method=self._modbus_mode, port=self._modbus_port, timeout=self._modbus_timeout, baudrate=self._modbus_speed)
else:
    connection = ModbusTcpClient(host=self._modbus_trovis_ip, port=self._modbus_trovis_ip_port)

Rock solid - je nach Konfiguration meines LAN-Serial-Adapters an der Trovis wahlweise mit RTU und TCP (einstellbar). Das macht die häufig benutzten socat- und mbusd-Umwege obsolet, die man bei RTU sonst immer gehen musste. Selbst meine Trovis-Smartphone-App verbindet sich jetzt direkt und ohne Raspi-/VM-Umweg, während das Plugin in der shNG-VM gleichzeitig Daten aus dem Gerät ausliest.

/tom

p.s. Oben werden bewusst beide Bibliotheken (RTU und TCP) unabhängig von den Einstellungen in der etc/plugin.yaml immer importiert. Ich habe mir bei allen Versuchen, den String für rtu/tcp aus der plugin.yaml schon da oben einzulesen und auszuwerten, die Ohren gebrochen ...