SmartHomeNG Release v1.8

[Morg]

Wenn der Port 8383 schon belegt ist, läuft vielleicht noch eine alte Instanz von shng?

In deiner Konfig haben das websocket- und das mqtt-Modul beide Port 2424 (auch wenn das auskommentiert ist). Soll das so?

[schloessl]

Ich kämpfe mit der Basis, irgendetwas schnalle ich nicht mehr!

Der Port 8383 ist immer belegt!

auf einem 2. PI läuft die Produktivversion mit der Vorgängerversion. Wird hier der Port 8383 blockiert?

2021-02-02 12:16:36 WARNING lib.smarthome.main -------------------- Init SmartHomeNG 1.8.1.master (84873f74) --------------------
2021-02-02 12:16:36 WARNING lib.smarthome.main Running in Python interpreter 'v3.8.6 final', from directory /usr/local/smarthome
2021-02-02 12:16:37 WARNING lib.smarthome.main - on Linux-5.4.83-v7l+-armv7l-with-glibc2.28 (pid=4483)
2021-02-02 12:16:37 WARNING lib.smarthome.main - Nutze Feiertage für Land 'DE', Provinz 'BY', 2 benutzerdefinierte(r) Feiertag(e) definiert
2021-02-02 12:16:38 CRITICAL modules.http Error starting http module: port 8383 is already in use
2021-02-02 12:16:38 ERROR lib.module Modules: Module 'http' initialization failed, module not loaded
2021-02-02 12:16:38 ERROR modules.admin Module 'admin': Not initializing - Module 'http' has to be loaded BEFORE this module
2021-02-02 12:16:38 ERROR lib.module Modules: Module 'admin' initialization failed, module not loaded
2021-02-02 12:16:42 ERROR plugins.darksky Plugin 'darksky': Not initializing the web interface
2021-02-02 12:16:42 ERROR lib.plugin Plugins: Plugin 'darksky' initialization failed, plugin not loaded
2021-02-02 12:16:42 ERROR plugins.database Plugin 'database': Not initializing the web interface
2021-02-02 12:16:42 ERROR plugins.onewire.owbase 1-Wire: could not connect to 127.0.0.1:4304: [Errno 111] Verbindungsaufbau abgelehnt oK noch nicht dran
2021-02-02 12:16:42 ERROR plugins.onewire Not initializing the web interface
2021-02-02 12:16:43 ERROR plugins.smartvisu Plugin 'smartvisu': Not initializing the web interface
2021-02-02 12:16:43 ERROR plugins.avm Plugin 'avm': Not initializing the web interface
2021-02-02 12:16:43 ERROR lib.plugin Plugins: Plugin 'avm' initialization failed, plugin not loaded

%YAML 1.1
---
# etc/module.yaml
# support for web server
http:
    module_name: http
    starturl: admin
    showtraceback: true

# support for graphical admin interface
admin:
    module_name: admin
#    developer_mode: true

#    websocket_host: 192.168.178.34

websocket:
    module_name: websocket
    # tls_key: myprivate.key
    # use_tls: true
    # tls_cert: myprivate.pem
    # port: 2424
    # tls_port: 2425

mqtt:
    module_name: mqtt
    #port: 2424
    #tls_port: 2425
    #tls_key: myprivate.key
    #tls_cert: myprivate.pem
    #use_tls: true
#enable, if mqtt protocol is going to be used



%YAML 1.1      PLUGINS
---
database:
    #Version1.8
    plugin_name: database
    class_path: plugins.database
    precision: '4'
    driver: pymysql
    connect:
    -   host:localhost
    -   user:root
    -   passwd:smarthome
    -   db:smarthome
    -   port:3306
    cycle: 3600

knx:
    plugin_name: knx
    plugin_enabled: False
    host: 127.0.0.1
    port: 6720
    #send_time: 600    # update date/time every 600 seconds, default none
    #time_ga: 0/7/0    # default none
    #date_ga: 0/7/1    # default none
    #busmonitor: on    # log all knx messages, default off
    #readonly: True    ## don't write to knx bus, default False

cli:
    class_name: cli
    class_path: plugins.cli
    #ip: 0.0.0.0
    #port: 2323
    #update: True
    #hashed_password: 1245a9633edf47b7091f37c4d294b5be5a9936c81c5359b16d1c48337$


ow:
    plugin_name: oneWire
    # Version 1.8  
#    class_path: plugins.onewire
    host: 127.0.0.1
    port: 4304
    cycle: 900
    log_counter_cycle_time: 5
#   DEV Version einsetzen


# 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

weather_darksky:
    class_name: DarkSky
    class_path: plugins.darksky
    key: b158462ff8ea6953eae8c5aad59241ae
    latitude: '48.60794391'
    longitude: '11.56989634'
    lang: de
    cycle: '600'



fb1:
#   Version 1.8
    class_name: AVM
    class_path: plugins.avm
    username: xx       # optional
    password: yyyy
    host: fritz.box
    port: 49443   # bei  ssl
##     port: 48704  # ohne  ssl
    cycle: 300
    ssl: True     # use https or not True / False
    verify: False     # verify ssl certificate
    call_monitor: 'True'
##     call_monitor_incoming_filter: "...    ## optional, don't set if you don't want to watch only one specific number with your call monitor"
    avm_identifier: fritzbox_7490


uzsu:
     plugin_name: uzsu

[Simikuen]

Jup, gib das mal so ein:

dlms_obis_code: ['C.1', '0', 'Value', 'str']

Besten Dank. Hab den Fix zum Plugin eingespielt.

[Tom Bombadil]

wenn Du den Cache abschaltest

Cache ist bei mir grundsätzlich abgeschaltet, da ich eigentlich immer irgendwo am Schrauben bin (und auch wegen der Fehlersuche am letzten Wochenende wegen der fehlenden Daten + nicht ausgelieferten Widget-Änderungen). Im Grunde hab ich seit Jahren vergessen, den Cache wieder *ein*zuschalten.

Am Rande: Ließe sich das Minimizen der Dateien eigentlich auch wieder irgendwie steuern? Die Option .js/.min.js in der config scheint ja mittlerweile obsolet zu sein, wenn ich das richtig verstanden habe. Mit einer Abschaltmöglichkeit des 'Minimizings' hätte ich am Wochenende eine weitere potentielle Fehlerquelle ausschließen können.

und dann in der Konsole schaust, ob ein "series_cancel" geschickt wird

Lässt sich in einem der gängigen Browser die Konsole parallel in eine Datei wegschreiben? Dann würde ich das mal dauerhaft mitloggen lassen.

Zur Hardware: Hier läuft alles auf nem QNAP NAS (4 Celeron-Kerne 2.4GHz, 8GB Hauptspeicher). mariaDB ist standardmäßig beim QNAP-OS dabei, also 'quasi-nativ'. shNG/sV laufen auf diesem NAS in einer eigenen VM (Debian Buster, 3 von 4 Kernen, 4GB Hauptspeicher - sollte eigentlich satt reichen). Außer der VM erzeugt auf dem NAS eigentlich zu 99.9% der Zeit nichts Last, das Ding ist nur ein 'Datengrab'.

/tom

[Morg]

shng mit einigen zusätzlichen Plugins aufm Raspi (3), SV (nginx), DB und NFS (für raspi-Dateisystem) auf dem "großen" Server. (HP Gen8)

[Onkelandy]

Ich kann auch noch nicht ganz nachvollziehen, wann das "no series to cancel" bei mir kommt. Aber defintiv lieber so als dass shng ständig Daten von der DB rüber schaufelt, obwohl die nicht mehr gebraucht werden. Insofern finde ich dieses cancel Feature schon ganz wichtig.
Plots haben bei mir auch in der Vorwersion schon recht lange gedauert. shng läuft auf nem Raspi 4, die Datenbank auf nem X86 Synology. Hab daher mal begonnen, die Plots auf eigene Seiten auszulagern.

Ein erster Test mit dem alten Plugin ist soweit erfolgreich, selbst außerhalb des Netzwerks mit Reverse Proxy. Mal schauen, ob ich das Problem mit dem neuen Setup module/plugin isolieren kann. Bei mir läuft übrigens alles außer der DB auf dem gleichen Raspi4. Wie sieht das bei dir aus Morg ?

[wvhn]

Auch scheinen die Plots manchmal nicht aktualisiert zu werden - die Zeitachse im Plot läuft weiter, aber die Linien werden nicht weitergezeichnet (=leerer Plotbereich rechts).

Hier wäre es hilfreich, wenn Du den Cache abschaltest und dann in der Konsole schaust, ob ein "series_cancel" geschickt wird. Das soll eigentlich nur bei Seitenwechsel gesendet werden, aber der auslösende Event ist schwer abzugrenzen. Popups, Selects usw. habe ich abgefangen, aber vlt. gibt es noch weitere Visu-Elemente, die einen Event 'Pagecontainerbeforechange' auslösen.

Man könnte natürlich auf series_cancel verzichten, aber dann sendet der Websocket von shNG alle jemals von der Visu angeforderten Plotdaten weiter, auch wenn die Seiten mit den Plots schon längst nicht mehr angezeigt werden.

Gruß
Wolfram

[Tom Bombadil]

Aktuell scheint die Verbindung zwischen SV und shng sehr wackelig bzw. phasenweise extrem langsam zu sein.

Kann ich so bestätigen. Besonders auf Seiten mit Plots, die früher fast 'instant' kamen, dauert der Seitenaufbau jetzt 5s+. Auch scheinen die Plots manchmal nicht aktualisiert zu werden - die Zeitachse im Plot läuft weiter, aber die Linien werden nicht weitergezeichnet (=leerer Plotbereich rechts).

Bis jetzt habe ich als Schuldigen für den langsamen Seitenaufbau eher das dB-Modul vermutet, da die 'Rohseite' immer noch fast instant da ist, nur halt mit leeren Plots, die dann nach einer Weile 'nachgereicht' werden. Bin da aber noch nicht tiefer eingestiegen, da es es grundsätzlich erstmal läuft und andere Baustellen zur Zeit offen sind.

/tom

[Sipple]

die codes 1001 und 1006 hatte ich bisher noch nicht, aber trotz Fix in der 1.8.1 habe ich immer noch sporadisch die 1005er ERRORS

2021-01-31  21:32:03 ERROR    modules.websocket   smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1005 (no status code [internal]), no reason
2021-01-31  21:32:05 ERROR    modules.websocket   smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1005 (no status code [internal]), no reason
2021-01-31  21:32:07 ERROR    modules.websocket   smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1005 (no status code [internal]), no reason
2021-01-31  21:32:09 ERROR    modules.websocket   smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1005 (no status code [internal]), no reason
2021-01-31  21:32:09 ERROR    modules.websocket   smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1005 (no status code [internal]), no reason

[Morg]

Andy, kann ich bei mir nicht bestätigen.1.8.1, SV 3.0, websocket-Modul, sv-Plugin (allerdings nur für Protokoll, nicht für Generierung). Keine Verbindungsprobleme, keine Verzögerungen.

[Onkelandy]

Ich habe bei mir gröbere Probleme mit dem Websocket Modul. Setup ist sonst 1:1 wie bei 1.7.2. nginx, neueste Smartvisu. Aktuell scheint die Verbindung zwischen SV und shng sehr wackelig bzw. phasenweise extrem langsam zu sein. Die Werte auf einer SV Seite werden erst nach 10-20 Sekunden gefüllt, auch wenn die Seite recht simpel ist. Cache an/aus, Reverse proxy oder direkt über die interne IP - beides macht keinen Unterschied.

Die Debug Console zeigt keine Fehler, dort ist nur zu beobachten, wie eben die Daten zeitverzögert rein kommen.
Habe in shng auch immer wieder Fehler wie diese:

Feb 02 09:16:37 WARNING modules.websocket Series cancelation: No series for path licht.og.terrasse.wand.sa found in list
Feb 02 09:16:37 ERROR modules.websocket smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1006 (connection closed abnormally [internal]), no reason
Feb 02 09:16:38 ERROR    modules.websocket smartVISU_protocol_v4: Exception in 'await websocket.send(reply)': code = 1001 (going away), no reason

Leider keine weiteren Anhaltspunkte. Ich hab da einfach nur ein paar Seiten in der Visu aufgerufen. Hat sonst niemand Probleme mit dem Modul in Kombo mit dem neuen smartvisu Plugin?

Ich stelle jetzt mal zurück aufs alte Plugin ohne Modul und beobachte.

[thengsty]

Hat sich erledigt. es muss hinter dem Wert für den cycle noch die Einheit geschrieben werden. Mit "cycle: 1s" funtioniert es.

Danke für den wertvollen Tipp! Das scheint sich seit 1.8 geändert zu haben und die Angabe der Einheit ist nun mandatory. In der Doku steht noch nichts davon. Sollte man das anpassen?
Doku:

Der Wert für dauer kann auf folgende Weise angegeben werden:

VG

[bmx]

Es gibt einen Fix im develop branch.

[Onkelandy]

Jup, gib das mal so ein:

dlms_obis_code: ['C.1', '0', 'Value', 'str']

[Simikuen]

Hallo,

hat sich erledigt. soeben einen Betrag gefunden dazu.

ich bin von SmartHomeNG v1.7 auf SmartHomeNG v1.8.1 incl. Plugins umgezogen. Grundsätzlich läuft das System (Python v3.7, Docker Container wurde aus dem Dockerfile vom Smarthome GIT erstellt). Jedoch habe ich mit dem DLMS Plugin ein Problem.

unter v1.7 sieht das Log dazu so aus. Gut zu sehen ist das nur OBIS Code für die Items verwendet wird.

2021-02-01 21:08:33 DEBUG plugins.dlms Item 'Energiezaehler.Seriennummer' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 21:08:33 DEBUG plugins.dlms The OBIS Code 'C.1' is added to the list of codes to inspect
2021-02-01 21:08:33 DEBUG plugins.dlms Item 'Energiezaehler.Einheit' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 21:08:33 DEBUG plugins.dlms The OBIS Code '1.8.0' is added to the list of codes to inspect
2021-02-01 21:08:33 DEBUG plugins.dlms Item 'Energiezaehler.Energie' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 21:08:33 DEBUG plugins.dlms The OBIS Code '1.8.0' is added to the list of codes to inspect

2021-02-01 21:14:40 DEBUG plugins.dlms Set item Energiezaehler.Seriennummer for Obis Code C.1 to Value 1ITR0054235901
2021-02-01 21:14:40 DEBUG plugins.dlms Set item Energiezaehler.Einheit for Obis Code 1.8.0 to Value kWh
2021-02-01 21:14:40 DEBUG plugins.dlms Set item Energiezaehler.Energie for Obis Code 1.8.0 to Value 16508.3

bei der v1.8.1 sieht es nun so aus. Der OBIS Code ist nun ein Array und kein einzelner Wert mehr. Dadurch wird das zugehörige Item nicht geändert.

2021-02-01 17:41:38 DEBUG plugins.dlms Item 'Energiezaehler.Seriennummer' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 17:41:38 DEBUG plugins.dlms The OBIS Code '['C.1', 0, 'Value', 'str']' is added to the list of codes to inspect
2021-02-01 17:41:38 DEBUG plugins.dlms Item 'Energiezaehler.Einheit' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 17:41:38 DEBUG plugins.dlms The OBIS Code '['1.8.0', 0, 'Unit', 'str']' is added to the list of codes to inspect
2021-02-01 17:41:38 DEBUG plugins.dlms Item 'Energiezaehler.Energie' has Attribute 'dlms_obis_code' so it is added to the list of items to receive OBIS Code Values
2021-02-01 17:41:38 DEBUG plugins.dlms The OBIS Code '['1.8.0', 0, 'Value', 'num']' is added to the list of codes to inspect

2021-02-01 19:42:46 DEBUG plugins.dlms Exception ''int' object is not iterable' occurred, please inform plugin author!
2021-02-01 19:43:47 DEBUG plugins.dlms Exception ''int' object is not iterable' occurred, please inform plugin author!
2021-02-01 19:44:46 DEBUG plugins.dlms OBIS Code 'F.F' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:44:46 DEBUG plugins.dlms OBIS Code 'C.1' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:44:46 DEBUG plugins.dlms OBIS Code 'C.5.0' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:44:46 DEBUG plugins.dlms OBIS Code '1.8.0' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:44:46 DEBUG plugins.dlms No more data available to read
2021-02-01 19:45:46 DEBUG plugins.dlms OBIS Code 'F.F' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:45:46 DEBUG plugins.dlms OBIS Code 'C.1' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:45:46 DEBUG plugins.dlms OBIS Code 'C.5.0' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:45:46 DEBUG plugins.dlms OBIS Code '1.8.0' '["['C.1', 0, 'Value', 'str']", "['1.8.0', 0, 'Unit', 'str']", "['1.8.0', 0, 'Value', 'num']"]' is not interesting...
2021-02-01 19:45:46 DEBUG plugins.dlms No more data available to read

die YAML sieht wie folgt aus. Die Spezifizierer hatte ich auch schon in einfache Hochkommas. Ohne Erfolg.

Energiezaehler:
    Seriennummer:
        type: str
        dlms_obis_code:
            - C.1
            - 0
            - Value
            - str
    Einheit:
        type: str
        dlms_obis_code:
            - 1.8.0
            - 0
            - Unit
            - str

Hat jemand eine Idee oder Tipp für mich.

Vielen Dank im Voraus.

Grüße
Mirko