@willi-wunder Wie vermutet, lag es an der zusätzlichen Komplexität des Somfy-Gerätes. Ich würde gerne ein neues Release des Adapters ausrollen, muss mich dazu aber erst mal mit seinem Schöpfer in Verbindung setzen, zwecks Berechtigungen.

@sputnik24 Bevor du migrierst, warte bitte noch kurz. Wir überlegen, ob man den Namen der Retention nicht per Config änderbar machen sollte, sodass man z.B. in deinem Fall den Adapter dazu bringen kann, "autogen" weiter zu nutzen.

@mike2712 Das hinter deinem Gateway-Namen ".loacal" statt ".local" steht, ist seltsam.

Bei Docker gäbe es zwei Möglichkeiten:

• Du verwendest beim Deployment --add-host (https://docs.docker.com/engine/reference/commandline/run/#add-entries-to-container-hosts-file---add-host) und fügst das IP-Hostname-Mapping hinzu. Bei docker-compose wäre das Der extra_hosts Abschnitt.
• Du zwingst deinen Container via --network=host (https://docs.docker.com/network/host/) das Netzwerk des Host-Systems direkt mit zu nutzen, dann wird sicher auch die hosts-Datei deines Betriebssystems bei der Namensauflösung verwendet. Damit hebst du aber auch einen Teil der Docker Container-Isolierung auf, was nicht so optimal ist. Daher würde ich immer eher zu Option 1 raten.

@mcm57 said in [Anfänger] SNMP Adapter - Fragen Veröffentlichung v Updates:

Ich plane sowieso den snmp Adapter echt zu forken (z.B. als snmp-plus) da ich hier zB. die Konfiguration ob ich snmp V1 / V2 / V3 verwenden will einbauen will. Außerdem passt die Konfig m.E. nicht 100 %. Eigenlicht sollte man x Geräte (=IPs) anlegen können und dann je IP y OIDs. Ich seh das als Übrungs / Scchulungsprojekt. Ob dass dann public wird wird sich zeigen.

McM

Wenn du den Adapter ohnehin grundlegend überarbeiten willst, kann ich dir nur empfehlen statt alten Code zu forken gleich einen "sauberen" neuen & "leeren" Adapter mit https://github.com/ioBroker/create-adapter zu erstellen, und dort dann mittles SNMP Lib deine Lösung zu implementieren. Durch den Adapter-Creator kriegst du extrem viele Sachen Out-of-the-Box, z.B. Github Build & Release Workflows inkl. Standard Testcases, AlCalzone's Release Script, Dependabot, die du sonst früher oder später vermissen wirst und nachträglich ans Laufen kriegen musst. Zudem hast du da Code-seitig ein einheitliches Grundgerüst, das viele ioBroker Adapter verwenden und du so ggf. auch mal in den Quellcode von anderen Adaptern "zur Inspiration" reinschauen kannst.

Der aktuelle Adapter scheint ja code-seitig nicht besonders viel zu machen und 90% würdest du wahrscheinlich sowieso umschrieben, also könnte der "frische Start" schon sinnvoll sein.

@stenmic Mit dem aktuellen Release geht es erst einmal darum eine grundlegende Unterstützung für InfluxDB 2 zu schaffen.

Die Möglichkeit verschiedene Retention-Policies (wie im Ticket beschrieben) je nach Datenpunkt zu nutzen, sieht für mich auf den ersten Blick technisch machbar aus (zumindest mit Influx 2.0), allerdings steckt da augenscheinlich einiges an zusätzlicher Arbeit drin:

• Man muss ggf. im Adapter die Konfigurationsseiten "aufbohren", damit man verschiedene Retention-Policies per Datenbank/Bucket pflegen (hinzufügen, ändern, entfernen) kann.
• Da der Adapter mit dem neuen Release zwei völlig unterschiedliche Bibliotheken zum Zugriff auf Influx 1/2 nutzt, müsste man "im Hintergrund" die Logik zweimal implementieren. in der Hoffnung natürlich, dass das Konzept bei beiden DB-Versionen auch gleich umgesetzt wurde, da es ansonsten für den normalen Nutzer bzgl. Adapter-Konfiguration zu komplex wird.
• Wenn es pro Datenpunkt einstellbar sein soll, muss man da auch nochmal an den Konfigurationsseiten Einiges optimieren.

Alles in allem denke ich, dass es sich hierbei um ein zustätzliches Wunsch-Feature handelt, das man sich nochmal separat anschauen muss. Interessant ist es auf jeden Fall.

Bzgl. Themen:

Falls Interesse besteht, teile ich gerne mal den Stand zu einem VIS Widget (3D Model) an dem ich gerade arbeite: https://github.com/Excodibur/ioBroker.vis-3dmodel.

@willi-wunder Wäre es möglich, dass du dir meine Version (https://github.com/Excodibur/ioBroker.tahoma) mal installierst, den Log auf "debug" stellst, und mir alle "Response:" - Einträge schickst? Gerne auch per PN.

Bitte schaue vorher nochmal drüber, dass keine personenbezogenen Daten drin sind. An einigen Stellen könnte deine private Mailaddresse, oder unter location deine private Anschrift aus der Tahoma-Box stehen. Am besten vorher ersetzen, oder löschen.

Ich habe bei mir die Antworten von Somfy/Tahoma für meinen Account ebenfalls erfasst und könnte dann auf der Basis vergleichen, wie sich deine Device-Daten von meinen unterscheiden und isolieren, wo es im Adapter hängt. Genauer noch suche ich nach der Response die den String "SETUP-" enthält - dort stehen alle deine Geräte/Devices drin.

@stenmic Mit der aktuellen Version aus dem Github Repo sollte die Änderung der Vorhaltezeit jetzt berücksichtigt werden und das unabhängig vom Erstellungszeitpunkt der DB. In der README gibt es zudem nochmal eine ausführlichere Erklärung der Zusammenhänge bzgl. Vorhaltezeit (Retention Period).

Individuelle Vorhaltezeiten je State lassen sich allerdings nicht mehr konfigurieren, wobei es ja zugegeben auch vorher keinen Effekt hatte. Der Grund warum es ganz entfernt wurde, ist, weil Influx 2 das ganze Konzept von Retention-Periods überarbeitet hat und nur noch eine aktive Retention-Period pro Bucket/DB zulässt.

@willi-wunder Danke, ich hoffe ich komme dazu es mir die nächsten Tage mal genauer anzuschauen.

Ich vermute es hat damit zu tun, dass die Tahoma-API für ManufacturerSettingsState statt eines einfachen Wertes (Zahl, Boolean) eine ganze Liste an Werten (discreet_mode_speed, roll_end_limit_state, setting_state, open_level, soft_start, current_position, soft_stop, nominal_mode_speed, unroll_end_limit_state, security_level) zurückgibt, die der Adapter dann alle in einem IOBroker State versucht abzuspeichern, was nicht geht. Daraufhin kommen dann die Fehlermeldungen. Wenn sich dass dann noch häuft, vermute ich mal, das der Adapter ein Problem bekommt.

Bei mir und meinen IO Rolläden ist dieser State nur "undefined", d.h. er wird nicht gepflegt und führt dann auch nicht zu Fehlern im Adapter-Code. Vielleicht hast du da neuere Somfy Komponenten eingebunden, die mehr Daten liefern, als die klassischen und das bringt den Adapter ins Stocken.

Als Entwickler ist es immer schwer, wenn man nicht die gleichen Geräte zur Verfügung hat, um solche Szenarien nachzustellen und zu beheben. Die Somfy-Doku ist an dieser Stelle auch quasi nicht existent. Ich überlege mal, was man da machen kann.

Der Adapter-Code wurde nochmal aktualisiert. Das History-Problem sollte jetzt behoben sein und beim Wechseln auf eine niedrigere Vorhaltezeit sollte es im Admin 5 eine Warnung geben.

Was aktuell noch nicht ganz sauber klappt, ist das Anzeigen von boolean-Werten in der History. Diese werden zwar angezeigt, allerdings werden zusätzlich noch zwei fiktive Werte mit angezeigt. Das passiert aber nur in der neuen Admin 5 Oberfläche und liegt vermutlich nicht am Influx Adapter. Ich bin hier noch auf Ursachen-Suche.

Da es auch nochmal einen wichtigen Fix im Admin 5.1.15 gab, muss jetzt diese Version (aktuell aus Beta/Latest) installiert werden, damit der Influx-Adapter überhaupt startet. Bitte daher zuerst ein Update vom Admin durchführen.

Bitte testet nochmal, ob es nun bei euch funktioniert, oder noch Fehler gibt.

@tradestation Hallo Axel, bitte schicke mir mal DEBUG-logs (https://github.com/Excodibur/ioBroker.tahoma/blob/master/FAQ.md#the-adapter-crashes-when-it-loads-devices-from-tahoma-or-sets-up-corresponding-states-incorrectly-what-can-i-do-to-help-the-developers-to-fix-this) damit ich mir das genauer anschauen kann.

@Jautze Ich kenne den spezifischen Typ Außenrollos jetzt nicht, aber denke das normale IO-Rollos mit dem Connectivity Kit funktionieren sollten. Soweit ich weiß, kann man beim Kit seine Geräte nur über die Online-API steuern, nicht wie bei den anderen Geräten auch über die lokale API (ohne Internet-Zwang), siehe auch https://github.com/Excodibur/ioBroker.tahoma#currently-tested-devices.

@imperator82 Wenn bei dir der InfluxDB Adapter installiert ist und läuft, kann du im Admin in der Objekt-Ansicht unter den Einstellungen (Zahnrad-Symbol) jedes States den du monitoren willst individuell InfluxDB "aktivieren" und dorf ggf. noch feintunen, unter welchen Bedingungen State-Änderungen in die Datenbank geschrieben werden sollen. Sobald dann was in den State geschrieben wird, landet das auch als Eintrag in der Datenbank.

Bzql. Daten-Abfrage kommt es drauf an, welche InfluxDB Version du verwendest. Bei Influx 1 gibt es eine SQL-artige Syntax (InfluxQL) mit der du die Daten abrufen kannst. Ab Influx 2 empfehle ich direkt Flux zu verwenden, was deutlich komplexere Abfragen ermöglicht. Ich setze die Anfragen selbst mit dem mitgelieferten CLI Tool ab, aber es geht wohl auch über einen UI-Server den man über einen anderen Port erreichen kann.

@imperator82 Schön dass es jetzt funktioniert.

Zu deinen Fragen kann ich leider nur bedingt Infos zusteuern, aber vielleicht weiß ja jemand anderes noch mehr hier.

1. Ich vermute mal, dass die Ventcube intern keine sprechenden Raumnamen verwendet, weil es für die techn. Funktion wahrscheinlich nicht erforderlich ist. Mir persönlich sind Raumnamen egal, da wir eine Fußbodenheizung haben, d.h. die Ventcube ist da außen vor und kennt die Temperatur unserer Räume (denke ich) gar nicht. Läuft bei einer Fußbodenheizung ja über Raumthermostate die direkt am Verteiler Ventile schalten.
2. Wenn du nachvollziehen können möchtest, wie lange bestimmte States (z.B. Zusatzheizung) einen bestimmten Wert (hier: an/aus) hatten, bietet sich eine Time-Series Datenbank an, da diese genau für solche Fälle ausgelegt ist. Ich kann hier nur InfluxDB (2) in Kombination mit ioBroker.influxdb empfehlen. Ergebnisse kann man z.B. dann auch über Grafana (o.Ä.) visualisieren.
3. Schwer zu sagen. Wenn es nicht in der offiziellen Ventcube API-Beschreibung drin steht, wird es schwer den Adapter entsprechend zu erweitern. Generell gibt es so einiges, was man anscheinend über das Bedienfeld einstellen/sehen kann, dass in der Modbus-Schnittstelle nicht auftaucht.
4. Hier kann ich leider nichts zu sagen, siehe (1).

@imperator82 Hmm, ich habe bei mir in den Netzwerkeinstellungen (im Ventcube-Kontrollpanel) noch 6. Serveranbindung auf freigegeben und 8. Serveranbindung auf verbinde, aber keine Ahnung, ob das hier hilft.

@imperator82 Log-files kannst du unter "Logs" in der Admin UI einsehen und nach Adapter filtern. Unter "Instanzen" kannst du im "Expert-Mode" in der Admin UI das Loglevel des Adapters ändern (Standard: Info).

Ich glaube aber nicht, dass mehr Logs hier helfen werden, weil die Ventcube bei dir von außen gar nicht erreichbar zu sein scheint, sonst würdest du kein Timeout bekommen. Das muss erst grundsätzlich möglich sein, sonst hat der Adapter keine Chance. Hast du nach dem Ändern der Einstellungen die Ventcube durch Aus-/Einschalten der Sicherung neu gestartet?

@imperator82 Hmm, bei mir ist das Leistungsteil V02.60 und Bedienteil V01.10, aber das liegt jetzt nicht wahnsinnig weit auseinander. Erreichst du die Ventcube prinzipiell (z.B. via telnet HERMES-LT 502, insbesondere von dort wo ioBroker läuft?)? Der Adapter muss bei solchen Verbindungstests deaktiviert sein, da die Modbus-Schnittstelle nur eine Verbindung zur gleichzeitig zulässt.

Gibt es sonst noch mehr Informationen, wenn du den Adapter auf DEBUG-Logging konfigurierst?

@mike2712 Das hinter deinem Gateway-Namen ".loacal" statt ".local" steht, ist seltsam.

Bei Docker gäbe es zwei Möglichkeiten:

• Du verwendest beim Deployment --add-host (https://docs.docker.com/engine/reference/commandline/run/#add-entries-to-container-hosts-file---add-host) und fügst das IP-Hostname-Mapping hinzu. Bei docker-compose wäre das Der extra_hosts Abschnitt.
• Du zwingst deinen Container via --network=host (https://docs.docker.com/network/host/) das Netzwerk des Host-Systems direkt mit zu nutzen, dann wird sicher auch die hosts-Datei deines Betriebssystems bei der Namensauflösung verwendet. Damit hebst du aber auch einen Teil der Docker Container-Isolierung auf, was nicht so optimal ist. Daher würde ich immer eher zu Option 1 raten.

@mike2712 mDNS funktioniert bei mir zu Hause im von einer Fritzbox verwalteten Netz z.B. nicht, deswegen habe ich das immer aus.

Die IP-Adresse musst du bei dem von mir vorgeschlagenen Workaround in die hosts-Datei deines Betriebssystems (inkl. Hostname) eintragen. Läuft ioBroker auf Linux, normalerweise unter /etc/hosts, bei Windows meistens C:\Windows\System32\drivers\etc\hosts. Dort dann einen Eintrag in folgendem Format hinzufügen:

172.16.20.61  gateway-xxxxx-xxxxx-xxxxx.local gateway-xxxxx-xxxxx-xxxxx

xxxx ist natürlich deine individuelle Gateway-ID

@mike2712 Wenn du ab Version 0.7.2 die Gateway PIN aus der Konfiguration nimmst, verbindet sich der Adapter statt mit der lokalen API wieder mit Tahomalink (online).

Dein Fehler getaddrinfo EAI_AGAIN deutet darauf hin, das bei dir die lokale Namensauflösung nicht funktioniert, d.h. der Adapter findet zu dem Namen kein Gerät im lokalen Netz. Eine Lösung wäre in deinem Router zu schauen, welche IP zu der Domain (gateway-xxxxx-xxxxx-xxxxx.local) gehört und die auf dem System wo dein Adapter läuft direkt mit der IP in die lokale hosts Datei einzutragen und dann den Adapter neu zu starten.

@memme Ja, das ist einer der komplizierteren Bugs mit der lokalen API. Hängt mit https://github.com/Excodibur/ioBroker.tahoma/issues/149 zusammen, nur leider bin ich noch nicht dazu gekommen.

NilsReinecke created this issue in Excodibur/ioBroker.tahoma

closed Failed getting execution state on local api #149