SmartHomeNG Release v1.9.4

[Msinn]

Aktuelle Version

Stand 14. März 2023 ist im master Branch auf Github die Version v1.9.4 als stabile Version von SmartHomeNG verfügbar.
Nur die Version aus dem master Branch sollte für den produktiven Einsatz benutzt werden!



Was ist neu in SmartNomeNG v1.9.4?

Es handelt sich um ein Wartungsrelease, welches außer Bugfixes einige neue Features im Core und den Plugins, sowie einige neue Plugins enthält.

Eine Übersicht über alle Änderungen ist in den Release Notes zu finden. Die aktuellen Release Notes sind in der Anwender Dokumentation unter docs.smarthomeng.de zu finden.




Was ist beim Update auf v1.9 bzw. v1.9.4 zu beachten?

1. Die minimale Python Version mit der SmartHomeNG v1.9.x startet ist Python 3.7
2. Es gibt ein neues websocket Modul, welches das visu_websocket Plugin ersetzt. Dieses muss in der ../etc/module.yaml konfiguriert werden. Genaueres ist in der Dokumentation zu finden: https://docs.smarthomeng.de/konfigur...websocket.html
   Im Gegensatz zum bisherigen Plugin, welches nicht mehr benötigt wird, unterstützt das websocket Modul die parallele Nutzung über ws:// und wss://
3. Einige Plugins, die schon länger als veraltet (deprecated) gekennzeichnet waren, sind mit v1.9 aus SmartHomeNG entfernt worden. Falls noch Bedarf nach diesen veralteten Plugins besteht, können diese aus dem Plugin Archive herunter geladen werden.
4. Falls SmartHomeNG sonst als Linux systemd Service gestartet wird:
   1. Bitte dringend zunächst den Service abschalten
   2. erfolgreiche Installation abwarten, es sollten keine Fehler mehr im Log zu finden sein
   3. Service anpassen siehe https://docs.smarthomeng.de/installa...ng_daemon.html
   4. Service wieder in Betrieb nehmen
5. ACHTUNG: Das pluggit Plugin hat ein massives Update erfahren und die Version 2.x ist in der Konfiguration nicht kompatibel zum pluggit Plugin 1.x!
   Bitte in der Dokumentation des Plugins die Unterschiede nachlesen, bzw. nachlesen wie man erstmal mit der Version 1.2.3 des Plugins weiter arbeiten kann.
6. Falls die smartVISU zusammen mit dem neuen websocket Modul verwendet wird, muss das smartvisu Plugin konfiguriert sein.
7. Das neue smartvisu Plugin (mit v1.8 erschienen) sollte verwendet werden, da es eine bessere Integration in die smartVISU ermöglicht als das alte visu_smartvisu Plugin, welches als veraltet (deprecated) gekennzeichnet wurde.

Dokumentation

Unter https://www.smarthomeNG.de findet sich unser Blog. Die Dokumentation ist unter https://docs.smarthomeng.de zu finden. Mit dem aktuellen Release ist die Entwickler Dokumentation in die Anwender Dokumentation umgezogen. Es gibt keine separate Entwickler-Dokumentation mehr.

• Die für das Release aktualisierte Entwickler-Dokumentation ist unter https://docs.smarthomeng.de/entwickl...twicklung.html zu finden.

Der Develop Branch

Es findet eine aktive Weiterentwicklung statt, daher bitte mit einem Produktionssystem nicht auf den Entwicklungszweig gehen!
Man sollte nur auf den develop Branch gehen, wenn man genau weiß, was man da macht.
Es kann immer mal passieren, dass der develop branch aufgrund der laufenden Entwicklung in einem nicht lauffähigen Zustand ist.


Auch ein Mischen vom master Branch und develop Plugins kann, aber muß nicht klappen, da einige Plugins aus dem develop Branch Funktionalitäten des Core benötigen könnten, die im master branch noch nicht vorhanden sind. In diesem Fall wird das Plugin nicht laden und einen Log Eintrag schreiben.



Unterstützung

Natürlich gibt es hier im Forum Unterstützung. Zusätzlich haben wir auf https://gitter.im/smarthomeNG/smarthome einen Chat für SmartHomeNG eingerichtet. Dort schauen viele User und Entwickler in regelmäßgen Abständen rein.



WICHTIG: Unterstützung bei Fragen und Problemen

Bevor ihr postet oder um Hilfe fragt, bitte

• im Administrations-Interface einen Überblick verschaffen ob z.B. config files richtig im SmartHomeNG ankommen
• Im Logfile nach Fehlern oder Warnungen suchen und wenn möglich deren Ursachen beseitigen.
• SmartHomeNG im Debugmodus starten oder besser: Für nur den betroffenen Teil den Log-Level auf INFO oder DEBUG hochsetzen.

Wenn Ihr Hilfe braucht und nicht weiterkommt werden Euch andere hier im Forum gerne weiterhelfen.



Wenn ihr dann postet, geizt bitte nicht mit Informationen über eure Installation. Wir können alle nicht Hellsehen. Für uns hilfreich oder sogar notwendig sind unter anderem:

• Beschreibung was ihr erreichen wollt
• Erläuterung was ihr bisher gemacht habt
• Genaue Bescheibung des wahrgenommenen Problems
• ("Läuft nicht" ist da nicht ausreichend...)
• Erläuterung welches Verhalten ihr erwartet
• SmartHomeNG Version
• Python Version
• Betriebssystem mit Version
• eingesetzte Hardware
• Art der Installation
• (z.B. Nach Komplettanleitung oder Raspberry Pi Image oder Update von Vorversion oder ...)
• Konfigurierte Plugins (gerne die etc/plugin.yaml mit posten)
• gegebenfalls die entsprechenden Item Konfigurationen (aus items/*.yaml)

Viel Spaß und viel Erfolg mit Eurem SmartHomeNG!!!

[henfri]

Vielen Lieben Dank allen Beteiligten!

[Tom Bombadil]

Danke für all die Arbeit, Martin!

Eine kurze Frage - war es in der Vergangenheit auch schon üblich, in den Release Notes die Beschreibung der Plugin-Änderungen massiv zu kürzen? Das mit dem Helios-Plugin verstehe ich ja noch, aber beim Trovis-Plugin sind etliche "derbe" Erweiterungen und Änderungen und sogar neu unterstützte Modelle drin, die zumindest ein reiner Leser der Release Notes nicht bzw. nur mit 'try & error' mitbekommt.

Aktuelle Release Notes:

• trovis557x:
  • changes to Samson Trovis 557x plugin (for new pymodbus versions
• helios:
  • changes to Helios Modbus RTU plugin (metadata only)

Originaltext aus dem PR:

• trovis557x changes: Released Plugin v2.0.0
  • Added support for Python 3.8+ and pyModbus3 (auto-switch between pymodbus2.2+/3.0+)
  • Added ModbusTCP support (for adapters with built-in TCP/RTU gateway like USR-TCP-K7 or USR-TCP232-E2)
  • Changed connection behaviour - added connect() and disconnect() to regular polls (formerly only at startup)
  • Updated register/coil tables, added new information, revised existing information, included Rk3 for 5579
  • Updated plugin.yaml: Rev 2 in format x.x.x, status 'ready', added 'werte' attribute to prevent errors in log
  • Removed unnecessary development files (templates, tools, assets) from official shNG-Plugins repo
  • Updated trovis.yaml items file, added Rk3+Sensors (e.g. for 5579)
  • New optional item attribute 'invalid_to_zero' to change response of 32767 (=switched off/unavailable/error) to 0
  • Updated Wiki, included A LOT of useful background information: github.com/Tom-Bom-badil/samson_trovis_557x/wiki
• helios changes: Included additional attributes in plugin.yaml
  • These changes will not affect any functionality at all and are just a 'convenience patch'.
    The 'new' attributes are defined within the plugin at runtime and have already been around since >8 years.
    At some point, they started to spam the logfiles with 'attribute undefined' errors for each single one of them.
    Consequently, they are now included in the plugin's attribute list to avoid those unnecessary logfile entries.

Falls die Antwort 'ja' ist - kann ich mir dann ausführliche Beschreibungen bei zukünftigen PR's einfach sparen?

/tom

[Msinn]

Eine kurze Frage - war es in der Vergangenheit auch schon üblich, in den Release Notes die Beschreibung der Plugin-Änderungen massiv zu kürzen?

Nein, in der Vergangenheit war es üblich für die Plugins keine Infos in den Release Notes zu haben.
Ich habe vor einigen Releases angefangen die Commit Messages des Plugin Repos in die Release Notes zu übernehmen. Indofern findet keine Kürzung, sondern eine Erweiterung der Release Notes statt.

Wenn die Release Notes jedoch "Roman-Character" hatten, habe ich das wichtig erscheinende in die Release Notes zu übernehmen. (Die Pflege der Release Notes für die Plugins ist mit nicht unerheblichem Aufwand verbunden. Wenn Du das übernehmen willst: Highly welcome).

Wenn mir dabei etwas wichtiges durchgerutscht ist, tut mir das leid, aber so ist es.

Wenn Du in Zukunft deutlich machst, was von den Infos essentiell ist, werde ich es übernehmen. Falls es um eine umfangreiche Versions-Historie geht, wäre das etwas für den Abschnitt Version History der user_doc.rst.