Probleme nach dem Update auf 1.9.4

[ivande]

bei mir gibt es nach dem Update auch Probleme: SH bleibt beim Starten hier hängen.

2023-03-16  09:38:08 NOTICE   lib.smarthome       --------------------   Init SmartHomeNG v1.9.4-master (c0cfb39cd)   --------------------
2023-03-16  09:38:08 NOTICE   lib.smarthome       Running in Python interpreter 'v3.9.2 final', from directory /usr/local/smarthome
2023-03-16  09:38:08 NOTICE   lib.smarthome        - operating system 'Raspbian GNU/Linux 11 (bullseye)' (pid=5001)
2023-03-16  09:38:08 NOTICE   lib.smarthome        - on 'Raspberry Pi 3 Model B+ v1.3, 1GB (Sony, UK)'
2023-03-16  09:38:15 NOTICE   lib.smarthome        - Nutze Feiertage für Land 'DE', Provinz 'None', 1 benutzerdefinierte(r) Feiertag(e) definiert
2023-03-16  09:38:27 WARNING  plugins.sonos       Version of used Soco module not available
2023-03-16  09:38:35 ERROR    lib.smarthome       Unhandled exception: 'NoneType' object has no attribute 'update'
<class 'AttributeError'>
running SmartHomeNG v1.9.4-master (c0cfb39cd)
Exception:   File "/usr/local/smarthome/bin/smarthome.py", line 292, in <module>
    sh.start()
  File "/usr/local/smarthome/lib/smarthome.py", line 649, in start
    self.plugins = lib.plugin.Plugins(self, configfile=self._plugin_conf_basename)
  File "/usr/local/smarthome/lib/plugin.py", line 122, in __init__
    plugin_name, self.meta = self._get_pluginname_and_metadata(plugin, _conf[plugin])
  File "/usr/local/smarthome/lib/plugin.py", line 242, in _get_pluginname_and_metadata
    meta = Metadata(self._sh, (plugin_name+plugin_version).replace('.',os.sep), 'plugin')
  File "/usr/local/smarthome/lib/metadata.py", line 135, in __init__
    self.parameters.update(self.global_parameters)

Update:
es scheint an einem handgestrickten priv_xx Plugins zu liegen, wenn ich dieses deaktiviere startet SH ohne Fehler,..


image.png

[Msinn]

Kannst Du Deine etc/plugin.yaml posten?

Update: Hat Dein handgestrickter Plugin Parameter oder nur Item Attribute?

[ivande]

%YAML 1.1
---
database:
    plugin_name: database
    driver: pymysql
    connect:
    -   host:127.0.0.1
    -   user:smarthome
    -   passwd:***
    -   db:smarthome_db

# Autogenerierung von Webseiten für SmartVISU UND Aktivierung des Nutzdatenprotokolls über Websocket für die smartVISU
smartvisu_pages:
    plugin_name: smartvisu
    smartvisu_dir: /var/www/html/smartvisu
    #generate_pages: True
    #overwrite_templates: True
    #visu_style: std
    #default_acl: rw
    #handle_widgets: True

    #list_deprecated_warnings: False
knx:
    plugin_name: knx
    readonly: false

stateengine:
    plugin_name: stateengine
    log_level: 2
    log_directory: var/log/stateengine/
    startup_delay_default: 300
    suspend_time_default: 10800
    laststate_name_manually_locked: Locked
    laststate_name_suspended: Suspend
    log_maxage: 1
    plugin_enabled: true

telegram:
    plugin_name: telegram
    name: SH
    token: ***
    plugin_enabled: true
    
# priv_telegram:
    # plugin_name: priv_telegram
    # name: SH
    # token:
    # plugin_enabled: true

solaredge:
    plugin_name: modbus_tcp
    instance: solaredge
    host: 192.168.0.50
    port: 502
    cycle: 20
    plugin_enabled: true

#logoMB:
#    plugin_name: modbus_tcp
#    instance: logomb
#    host: 192.168.0.80
#    port: 502
#    cycle: 20
#    plugin_enabled: true

logoheizraum:
    plugin_name: snap7_logo
    instance: logoheizraum
    host: 192.168.0.76
    tsap_server: 0x200
    tsap_client: 0x100
    plugin_enabled: true
#    cycle: 5
Sonos:
    plugin_name: sonos
    tts: true                          # optional, default:  false
    local_webservice_path: /usr/local/smarthome/media/sounds    # optional, default:  empty. If 'tts' is enabled, this option is mandatory.
                                         # All tts files will be stored here.
    #local_webservice_path_snippet: /usr/local/smarthome/media/sounds
    # webservice_ip: 192.168.1.40        # optional, default:  automatic. You can set a specific ip address.
                                         # If you're using a docker container, you have to set the host
                                         # ip address here.  
    # webservice_port: 23500             # optional, default:  23500
    discover_cycle: 120                # optional, default:  120 (in seconds)
    speaker_ips:                       # optional. You can set static IP addresses for your Sonos speaker. This
    -   192.168.0.141                         # will disable auto-discovery. This is useful if you're using a
    plugin_enabled: true

fb1:
    plugin_name: avm
    username: smarthome
    password: ***
    host: fritz.box
    port: 49000
    cycle: 300
    ssl: true     # use https or not # ssl: True
    verify: false # verify ssl certificate
    call_monitor: true
    #avm_identifier: fritzbox_1
    instance: fritzbox_7490
    plugin_enabled: true
uzsu:
    plugin_name: uzsu
    plugin_enabled: true

roto:
    plugin_name: priv_roto
    plugin_enabled: true

clickcontrol:
    plugin_name: priv_clickcontrol
    plugin_enabled: true

[ivande]

Update: Hat Dein handgestrickter Plugin Parameter oder nur Item Attribute?

nur attribute

es dürfte am roto-Plugin liegen.. Fehler ist jedoch erst aufgetaucht nach dem update von 1.9.3 auf 1.9.4. und apt-get update & upgrade
https://github.com/ivan73/roto_plugin

Gruß Ivan

Update:
hab in der plugin.yaml des roto-Plugin noch das NONE hinzugefügt, nun läuft es wieder.

parameters: NONE
# Definition of parameters to be configured in etc/plugin.yaml

[Morg]

Der Fehler ist der gleich, wie bei fuxl66

Ich arbeite an einem Fix und melde mich.

PS:
Wir könnten das auch in den Thread vom AVM Plugin verlegen

Ich verlege mal nach AVM:..

[ooUrmeloo]

Hallo,
ich hänge mich hier mal mit dran
Ich habe seit einem Neuaufsatz unter Bullseye, SmartHomeNG 1.9.4, Python 3.9.2, SmartVisu 3.3.1 einige Probleme mit einigen Plugins (u.a. auch Modbus_TCP, Database, UZS), weiß aber nicht 100%, ob es mein Neuaufsatz ist oder mit der 1.9.4 zusammen hängt.
Die gleiche Konfiguration (Plugins, Items, ...) läuft unter Buster, SmartHomeNG 1.9.3, Python 3.7.3, SmartVisu 3.3.1 einwandfrei ...

Für das UZSU Problem habe ich hier schon einen Thread erstellt:
https://knx-user-forum.de/forum/supp...98#post1856098

Ich habe aber auch Probleme mit dem Modbus_TCP:
Hier gab es gleich am Anfang schon mal einen Mismatch in den Version-Nummern in der "__init__.py" und in der "plugin.yaml". (1.0.7 vs 1.0.8) Trotz Korrektur, gibt es Probleme mit der Kommunikation:

2023-03-17  09:37:06 ERROR    pymodbus.logging    Connection to (192.168.178.67, 1502) failed: [Errno 111] Connection refused
2023-03-17  09:37:06 ERROR    plugins.modbus_tcp  solaredge@: could not connect to 192.168.178.67:1502
...
2023-03-17  09:37:09 ERROR    pymodbus.logging    Connection to (192.168.178.34, 502) failed: timed out
2023-03-17  09:37:09 ERROR    plugins.modbus_tcp  paradigma@: could not connect to 192.168.178.34:502

Hat jemand ähnliche Erfahrungen/Probleme beim Umstieg auf 1.9.4? Oder liegt's am Neuaufsatz? Wollte nicht bewusst auf 1.9.4 umsteigen ...
Wie gesagt, auf der "alten" Konfiguration läuft es ...

[eXcite]

Onewire funktioniert wieder.

Ich war noch auf Debian Buster mit der dort aktuellsten Python3 Version. Nach Upgrade auf Bullseye mit Python 3.9 läuft es wieder.

[Msinn]

Probleme mit einigen Plugins (u.a. auch Modbus_TCP, Database, UZS)

Zum database Plugin: Nutzt Du sqlite3? Falls ja, gib den Pfad zur Datenbank absolut an. Bei einer Reihe von Usern konnte die Datenbank mit einer relativen Pfadangabe nicht geöffnet werden.

[ooUrmeloo]

Zum database Plugin: Nutzt Du sqlite3? Falls ja, gib den Pfad zur Datenbank absolut an. Bei einer Reihe von Usern konnte die Datenbank mit einer relativen Pfadangabe nicht geöffnet werden.

Ja, das Problem hatte ich auch und es mit dem aktuellen Pfad auch bei mir behoben (hatte das auch schon gelesen gehabt).
Ich habe allerdings bisher nicht geschafft, die "alte" Datenbank einzulesen. Da kommt immer, dass die db korrupt ist o.ä. ...

[Msinn]

Wie willst Du die Datenbank denn "einlesen"? Du brauchst nur die Kopie aus der alten Version an die entsprechende Stelle zu kopieren. Wichtig ist dabei, dass die alte Version von SmartHomeNG vorher beendet ist, sonst kopierst Du einen nicht konsistenten Stand (weil nicht alle Daten auf der Platte sind).

[ooUrmeloo]

Wie willst Du die Datenbank denn "einlesen"? Du brauchst nur die Kopie aus der alten Version an die entsprechende Stelle zu kopieren. Wichtig ist dabei, dass die alte Version von SmartHomeNG vorher beendet ist, sonst kopierst Du einen nicht konsistenten Stand (weil nicht alle Daten auf der Platte sind).

genau das habe ich schon 2 mal versucht ... und dann konnte die DB nicht eingelesen werden und das Plugin ist ausgestiegen.
Evtl. hatte sie - wie Du sagst - keinen konsistenten Stand. Ich muss das heute Abend nochmal probieren.
Kämpfe aber erstmal noch mit den anderen Problemen ... s.o. bzgl. UZSU und Modbus. Der Rest scheint mittlerweile zu tun.

[Msinn]

Falls Du die alte Version vor dem Kopieren nicht beendet haben solltest, kann ich Dir garantieren, dass Du einen nicht konsistenten Stand kopiert hast.

[ooUrmeloo]

Falls Du die alte Version vor dem Kopieren nicht beendet haben solltest, kann ich Dir garantieren, dass Du einen nicht konsistenten Stand kopiert hast.

erwischt ...

apropos ... danke für die schnellen Antworten!

[Msinn]

Hallo,
ich hänge mich hier mal mit dran
Ich habe seit einem Neuaufsatz unter Bullseye, SmartHomeNG 1.9.4, Python 3.9.2, SmartVisu 3.3.1 einige Probleme mit einigen Plugins (u.a. auch Modbus_TCP, Database, UZS), weiß aber nicht 100%, ob es mein Neuaufsatz ist oder mit der 1.9.4 zusammen hängt.
Die gleiche Konfiguration (Plugins, Items, ...) läuft unter Buster, SmartHomeNG 1.9.3, Python 3.7.3, SmartVisu 3.3.1 einwandfrei ...

Für das UZSU Problem habe ich hier schon einen Thread erstellt:
https://knx-user-forum.de/forum/supp...98#post1856098

Ich habe aber auch Probleme mit dem Modbus_TCP:
Hier gab es gleich am Anfang schon mal einen Mismatch in den Version-Nummern in der "__init__.py" und in der "plugin.yaml". (1.0.7 vs 1.0.8) Trotz Korrektur, gibt es Probleme mit der Kommunikation:

2023-03-17 09:37:06 ERROR pymodbus.logging Connection to (192.168.178.67, 1502) failed: [Errno 111] Connection refused
2023-03-17 09:37:06 ERROR plugins.modbus_tcp solaredge@: could not connect to 192.168.178.67:1502
...
2023-03-17 09:37:09 ERROR pymodbus.logging Connection to (192.168.178.34, 502) failed: timed out
2023-03-17 09:37:09 ERROR plugins.modbus_tcp paradigma@: could not connect to 192.168.178.34:502

Hat jemand ähnliche Erfahrungen/Probleme beim Umstieg auf 1.9.4? Oder liegt's am Neuaufsatz? Wollte nicht bewusst auf 1.9.4 umsteigen ...
Wie gesagt, auf der "alten" Konfiguration läuft es ...

Ich nutze das Plugin nicht, aber die Log Einträge verraten mir folgendes:
Erster Fehler:
Das pymodbus Package meldet, dass das Device mit der IP Adresse 192.168.178.67 einen Verbindungsaufbau auf Port 1502 abgelehnt hat.
Die nächste Zeile ist die Meldung des selben Fehlers aus dem Plugin (nachdem das pymodbus Package den Fehler an das Plugin zurückgemeldet hat).

Zweiter Fehler:
Das pymodbus Package meldet, dass das unter 192.168.178.34 kein Device antwortet. Es gibt also kein aktives Device mit dieser IP Adresse in Deinem Netzwerk (oder das Device ist in einer Art "Stealth-Mode" und meldet Verbindungs-Ablehnungen nicht als Fehler zurück, sondern antwortet gar nicht).

[ivande]

Ich habe aber auch Probleme mit dem Modbus_TCP:
Hier gab es gleich am Anfang schon mal einen Mismatch in den Version-Nummern in der "__init__.py" und in der "plugin.yaml". (1.0.7 vs 1.0.8) Trotz Korrektur, gibt es Probleme mit der Kommunikation:

Die falsche Versionsnummer ist mir auch schon aufgefallen, die Verbindung zum Device hat bei mir auf Anhieb funktioniert...