@dslraser

Vielen Dank für Deine Unterstützung und den Tipp die Funktionen und Räume nicht auf der CCU, sondern in iobroker zu definieren!

In der Zwischenzeit habe ich die Funktionen und Räume im iobroker definiert und dafür gesorgt, dass nur noch die Namen meiner Homematic-Geräte von der CCU2 zum iobroker kommuniziert werden. Damit findet die Definition der für meine Progamme relevanten Datenpunkte nur noch an einem Ort im iobroker statt.

Der Grund dass der Bezeichner "battery" nach dem Neustart der Instanz hm-rega nicht
mehr vorhanden war, lag in der Tat an dem nicht kommunizierten Datenpunkt Kanal-0, wo sich der für mein Programm relevante Wert LOW_BAT befand. Dieser hatte ich in den
Einstellungen vom jeweiligen Homematic-Gerät vergessen zu aktivieren.

Da ich in meinem SmartHome-System die CCU2 nur noch als Kommunikations-Einheit
zur Funk-Übertragung der Steuerbefehle meiner Homematic-Geräte nutze und ich sämtliche JS-Skripte im iobroker erstelle und verwalte, macht es natürlich Sinn ebenfalls die Aufzählungen in iobroker zu definieren.

Bevor ich die Möglichkeiten von iobroker entdeckte, habe ich lediglich meine bestehenden Rollläden im SmartHome über die CCU2 gesteuert. im Frühling 2021 habe ich mich entschieden, weitere Homematic-Geräte in mein SmartHome zu integrieren, wobei ich den bestehenden Programmcode von der CCU2 in den iobroker migrierte, welcher auf einem RaspberryPi4 läuft.

Ich bedanke mich bei Euch für die professionelle Hilfe von @dslraser und das klärende Nachfragen von @homoran und bin dankbar, dass dieses iobroker-Forum mit solchen
qualifizierten Experten existiert.

Herzlichst
Kobi

Seit kurzer Zeit nutz ich Visual Studio Code mit der Extension ioBroke.javascript v1.5.1 zur Entwicklung meiner TypeScripts auf dem Target RaspberryPi5 (Debian, Node.js v20.17.0, NPM v10.8.2). Nachdem ich das Passwort vom autorisierten ioBroker-Benutzer geändert
hatte, wird keine Verbindung zum Target mehr aufgebaut. In der Beschreibung vom ioBroker.javascript Adapter wird erwähnt, dass nach der Änderung des Passworts VS Code neu zu starten ist. Dies habe ich mehrfach erfolglos versucht. Das Passwort wird scheinbar in den Gefilden von VS Code gespeichert. Eine Neuinstallation von VS Code erfragte zwar das aktuelle Passwort, doch es erscheint in VS Code stets folgende Meldung:

Could not connect to ioBroker. Check your '.iobroker-config.json' for wrong configuration.

Der Inhalt von meiner .iobroker-config.json sieht wie folgt aus:
{
"ioBrokerUrl": "http://10.0.0.13",
"socketIoPort": 8081,
"scriptRoot": "/",
"adminVersion": "admin7",
"allowSelfSignedCertificate": false,
"username": "Urs"
}

Im Protokoll von iobroker wird folgendes angezeigt:

admin.0 2024-08-27 11:32:29.095 warn Cannot login user: Too many errors. Try again in 3 minutes.
admin.0 2024-08-27 11:32:24.535 info failed connection to socket.io from 10.0.0.70: Passport was not initialized

Kann mir vielleicht jemand einen Tipp geben, was ich tun muss, damit die Verbindung zum Target wieder funktioniert?

Herzlichen Dank
Kobi

Re: HMIP RPC Adapter Error

Auch wenn mir bewusst ist, dass das von @WeiserWolf im März 2023 geschilderte Phänomen hier nicht direkt mit iobroker zu tun hat, möchte ich meine gemachten Erfahrungen diesbezüglich trotzdem gerne in diesem Forum kundtun.

Auch ich nutze seit Jahren Homematic Classic- und IP-Geräte, welche sich problemlos mittels iobroker ansteuern liessen. Auch mir ist aufgefallen, dass nach einem der letzten Firmware Updates der Homematic CCU3 das von @WeiserWolf geschilderte Phänomen sporadisch auftritt. Leider kann ich nicht sagen ab welcher Firmwareversion das Problem das erste Mal aufgetreten ist. Aktuell nutze ich die aktuellste Firmware Version 3.73.9.20231130. Ich habe dasselbe Problem mit derselben Firmware, sowohl mit der originalen Homematic CCU3 als auch mit der RaspberryMatic CCU3 festgestellt. Darum gehe ich davon aus, dass sich ein Software-Bug in der Ursprungs Software der Homematic CCU3 eingeschlichen hat, welcher ebenfalls in die RaspberryMatic CCU3 eingeflossen ist.

hm-rpc.1
2024-01-06 09:31:00.214	info	Temporary error occurred for "setValue" with "["00115D89913210:4","LEVEL",{"explicitDouble":1}]": XML-RPC fault: Generic error (UNREACH)

hm-rpc.0
2024-01-06 09:30:56.326	info	Temporary error occurred for "setValue" with "["QEQ1925483:1","LEVEL",{"explicitDouble":1}]": XML-RPC fault: Failure

hm-rpc.0
2024-01-06 09:30:55.062	info	Temporary error occurred for "setValue" with "["REQ1414015:1","LEVEL",{"explicitDouble":1}]": XML-RPC fault: Failure

So wie es für mich den Anschein macht, haben die Softwareentwickler der Homematic CCU3 etwas unbewusst geändert, was das Timing in der asynchronen internen Kommunikation beeinflusst und zu dem geschilderten Phänomen führt. Somit ist das Phänomen abhängig vom aktuell laufenden Traffic von asynchronen Prozessen und darum zufällig, wodurch es schwer zu reproduzieren ist.

Zu Testzwecken habe ich mein produktives Smarthome System anstelle der CCU3 (FW 3.73.9.20231130) mit einer alten CCU2 (FW 2.61.7) getestet und festgestellt, dass das System über mehrere Wochen stabil und ohne irgendwelche Störungen gelaufen ist. Dies beweist, dass es sich um ein Problem in der aktuellen Firmware der Homematic CCU3 handeln muss.

Da die veraltete CCU2 nicht mehr weiterentwickelt wird und gewisse Homematic Geräte einen minimalen Firmwarestand für die Pflege deren Gerätefirmware voraussetzen, bin ich natürlich interessiert meine Homematic Classic- und IP-Geräte in Zukunft mit der CCU3 zu betreiben.

Was mich etwas erstaunt, ist die Tatsache, dass man nicht mehr von potentiellen Homematic CCU3 Anwendern hört, welche doch dieselben Phänomene feststellen müssten? Ebenfalls kann ich mir nicht vorstellen, dass die Softwareentwickler der CCU3 das festgestellte Phänomen nicht entdeckt haben sollten?

Ich würde mich freuen, wenn es jemanden gibt, welcher eine direkte Verbindung zu den Entwicklern der Homematic CCU3 hat, um dieses störende Phänomen endgültig aus der Welt zu schaffen.

Herzlichst
Kobi

@duffy Danke für Dein aufschlussreiches Feedback. Bei den Unterschieden unserer Systemvoraussetzungen ist mir neben dem Pi mit Bookworm aufgefallen, dass Du gegenüber meiner eingesetzten SONOS-Version 2.3.1 die neuere Version 2.5.3 vom SONOS Adapter angegeben hast. Wo und wie komme ich zu der Version 2.5.3 vom SONOS-Adapter?

Gerne würde ich einen Versuch mit dem backitup Adapter unter js-Controller 5.0.12, mit installiertem SONOS Adapter v 2.5.3 durchführen um zu testen, ob der backitup Adapter immer noch einen Systemcrash auslöst.

@foxriver76 Update vom js-controller 4.0.24 nach 5.0.12 führt zum Systemcrash beim Start von Sicherung im backitup Adapter (2.6.23).

Während dem erwähnten Systemcrash lässt sich keine Verbindung zum Host via CLI herstellen, sodass danach keine Diagnose mittels [iob diag] mehr möglich ist und nur noch ein System Neustart Abhilfe schafft. Nach der Betätigung des Buttons <IOBROKER BACKUP STARTEN> sieht man im LOG-Fenster von backitup am Anfang noch lesbare Zeichen, danach werden nur noch Hieroglyphen dargestellt, bis schlussendlich der Admin Adapter abstürzt und nichts mehr funktioniert. Interessant ist die angezeigte Fehlermeldung:

Parsing error on getStates("io.sonos.0.root.10_0_0_62.cover_png), returning "null" for "?PNG

Mit der ursprünglichen js-controller Version 4.0.24 und den exakt gleichen verwendeten Versionsständen aller verwendeten Systemkomponenten funktioniert die Sicherung im backitup Adapter problemlos.

Diagnose mit installiertem js-controller 4.0.24:
iob_diag_js-controller 4_0_24.txt

Diagnose mit installiertem js-controller 5.0.12:
iob_diag_js-controller 5_0_12.txt

Es stellt sich für mich die Frage, ob es allenfalls am SONOS Adapter liegen kann, welcher ich installiert habe und seit Jahren mehr oder weniger problemlos nutze?

@mickym Danke für Deine prompte und kompetente Antwort!

Mit folgendem Befehl gemäss Deiner Beschreibung, lässt sich das MainWLAN korrekt ausschalten:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:WLANConfiguration:1","action": "X_AVM-DE_SetWLANGlobalEnable","params": {"NewX_AVM-DE_WLANGlobalEnable": 0}');

commandResult:
{}

Mit folgendem Befehl gemäss Deiner Beschreibung, lässt sich das MainWLAN korrekt einschalten:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:WLANConfiguration:1","action": "X_AVM-DE_SetWLANGlobalEnable","params": {"NewX_AVM-DE_WLANGlobalEnable": 1}');

commandResult:
{}

Mit folgendem Befehl gemäss Deiner Beschreibung, lässt sich der Anrufbeantworter[0] korrekt ausschalten:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:X_AVM-DE_TAM:1","action": "SetEnable", "params": {"NewIndex": 0,"NewEnable": 0}}');

commandResult:
{}

Mit folgendem Befehl gemäss Deiner Beschreibung, lässt sich der Anrufbeantworter[0] korrekt einschalten:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:X_AVM-DE_TAM:1","action": "SetEnable", "params": {"NewIndex": 0,"NewEnable": 1}}');

commandResult:
{}

Wie Du richtig bemerkts hast, wird der Befehl in commandResult nur quittiert, falls in der Befehlssequenz sowohl IN- als auch OUT-Parameter involviert waren!

Vielen Dank für Deine wertvolle Unterstützung!

@Apollon77 Soweit ich im Änderungsprotokoll sehen kann, bist Du des Öfteren mit dem Adapterunterhalt von tr-064 beschäftigt. Als Anregung wäre es für alle User sehr hilfreich, wenn der bestehende Datenpunkt (wlan) zum globalen Schalten aller aktiven WLAN Bänder (2.4 GHz, 5.0 GHz) genutzt werden könnte. Momentan funktioniert das leider nicht, sodass jeder User nur mittels eigenem Befehl via tr-064.0.states.command, ein sauberes Schalten vom MainWLAN, analog zur FritzBox WLAN-Taste realisieren kann. Vielleicht besteht ja die Möglichkeit, diesen Wunsch bei der nächsten Modifikationen einfliessen zu lassen?

Grüezi Community

Gemäss der publizierten AVM Dokumentation bzgl. der API für TR-064 Support WLANConfiguration wurde mit der Version 23 (23.03.2018, wlanconfigSCPD.pdf) die neue Action X_AVM-DE_SetWLANGlobalEnable implementiert.

Wenn ich diese richtig interpretiere, lässt sich damit das WLAN analog wie bei Betätigung der physischen WLAN-Taste an der FritzBox schalten. Die Schaltung geschieht unabhängig, des 2.4 GHz-, oder 5.0 GHz-, oder gleichzeitig aktivierten WLAN-Frequenzbandes.

In der github-Dokumentation vom ioBroker.tr-064 wird die Möglichkeit gezeigt, jedes Kommando gemäss der AVM FritzBox Spezifikation, als Json an die FritzBox zu
kommunizieren. Dazu wird exakt anhand eines Beispiels beschrieben, wie die Nachricht als Json verpackt an die FritzBox übermittelt werden kann.

Wennn ich das gezeigte Beispiel zum Schalten des Anrufbeantworters (x_tam.pdf) wie folgt verwende, wird als Antwort im commandResult nur {} empfangen:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:X_AVM-DE_TAM:1","action": "SetEnable", "params": {"NewIndex": "0","NewEnable": "1"}}');

commandResult:
{}

Wenn ich mit nachfolgendem Kommando z.B. einen spezifischen Telefonbucheintrag (x_contactSCPD.pdf) abfrage, erscheint im commandResult folgende korrekte Antwort im XML-Format:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:X_AVM-DE_OnTel:1","action": "GetPhonebookEntry","params": {"NewPhonebookID": 1, "NewPhonebookEntryID" : 6}}');

commandResult:
{"NewPhonebookEntryData":"<?xml version="1.0" encoding="utf-8"?><contact modified="0"><category>0</category><id>people/c268485185529455437</id><person><realName>Andreas Tobler</realName></person><telephony\nnid="2"><number type="label:Main" prio="1" id="0">+41 71 446 48 53</number><number\ntype="mobile" id="1">+41 79 433 71 93 </number></telephony><services\nnid="1"><email classifier="business" prio="1" id="0">andreastobler@gmx.ch</email></services><setup /><uniqueid>63</uniqueid><etag>%EgsBAgMJCycuNz0+PxoEAQIFByIMV1NtUEtKUjlXR289</etag></contact>"}

Soweit ich in der Community gesehen habe, existieren nicht wenige User, welche den tr-064 Adapter nutzen und festgestellt haben, dass es momentan nicht möglich ist, über die bereitgestellte tr-064 Schnittstelle das FritzBox-WLAN sauber schalten zu können.

Aus diesem Grund wollte ich mich erkundigen, ob jemand bereits erfolgreich mittels der oben beschriebenen Möglichkeit, die von AVM zur Verfügung gestellte Schnittstelle X_AVM-DE_SetWLANGlobalEnable zum Schalten des WLAN erfolgreich implementieren konnte?

Soweit ich die AVM API (wlanconfigSCPD.pdf) verstanden habe, sollte mit folgendem Kommando das FritzBox WLAN ein- bzw. ausgeschaltet werden können:

command:
setState('tr-064.0.states.command', '{"service": "urn:dslforum-org:service:WLANConfiguration:1","action": "X_AVM-DE_SetWLANGlobalEnable","params": {"NewX_AVM-DE_WLANGlobalEnable": "0", "X_AVM-DE_WLANGlobalEnable": "1"}');

commandResult:

Mit der Version 23 vom 23.03.2018 wurde von AVM diese neue Action eingeführt und ich verstehe nicht, warum in commandResult keine Antwort empfangen wird. Könnte es evtl. an der Implementation vom Adapter tr-064 liegen, oder mache ich einen Denkfehler bei der Interpretation der AVM API Spezifikation?

Falls jemand über das notwendige Wissen verfügt und mir zeigen könnte, wo ich auf dem Schlauch stehe, oder sogar den tr-064 Adapter um diese Schnittstelle zur
sauberen Schaltung vom FritzBox WLAN erweitern kann, wäre wahrscheinlich nicht nur ich überglücklich darüber?

In diesem Sinne besten Dank für Eure Unterstützung.

Herzlichst
Urs

@AlCalzone Danke für Deine schnelle, kompetente und ausführliche Antwort. Daraus konnte bestimmt nicht nur ich viele neue Erkenntnisse gewinnen.

Herzlichst
Kobi

Grüezi Community

Gerne möchte ich meine mittels typescript erstellten Skripte in Themen gegliederte Module organisieren. Bei meiner eingesetzten Hardware handelt es sich um den Raspberry Pi 4 mit folgenden Software Komponenten:

Platform Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 1500 MHz
Modell:ARMv7 Processor rev 3 (v7l)
RAM:3.7 GB
System-Betriebszeit: 11 T. 00:00:00
Node.js: v14.19.0
NPM: 6.14.16
Datenträgergröße: 28.2 GB
Festplatte frei: 22.0 GB
Adapter-Anzahl: 396
Betriebszeit: 2 T. 06:09:26
Aktive Instanzen: 20
Pfad: /opt/iobroker/
ts compiler version: 4.5.5

Damit ich besser verstehen kann, wo und wie das iobroker JS runtime Environment spezifische TS-Module speichert, sodass der TS-Compiler Code-Modifikationen erkennt und nur geänderte Module neu kompiliert, habe ich folgende zwei Bespiel TS-Module erstellt:

//TS-Module Test0:

export class MyClass {
constructor(val1: number, val2: number) {
this.v1 = val1;
this.v2 = val2;
}
public Get(): number {
return this.v1 * this.v2;
}
private v1: number;
private v2: number;
}

//TS-Module Test1:

moduleResolution: 'node' // option to specify the module resolution strategy
import { MyClass } from './Test0';
const obj = new MyClass(2, 3);
console.error(obj.Get());

Die beiden TS-Module befinden sich unter dem Standard Ordner common vom iobroker Editor und der Compiler meldet, dass er das TS-Module Test0 nicht finden kann.

Könnte mir jemand mit typescript Erfahrung bitte folgende Fragen beantworten?

• 1. Wo befinden sich die beiden TS-Module Test0 bzw. Test1 physikalisch?
• 2. Muss ich dem TS-Compiler den SRC-Pfad explizit bekannt geben und falls ja, wo befindet sich eine entsprechende tsconfig.json-Datei?
• 3. Muss ich dem TS-Compiler spezifische Optionen bekanntgeben, oder wurden diese bereits durch die TS-Projekt Erstellung automatisch erstellt?
• 4. Wo befinden sich die Build Dateien des Compilers auf dem System?
• 5. Ist für das iobroker runtime environment ein für node v14 passendes Paket zu installieren, damit eine TS-Modul Verwaltung im iobroker Editor überhaupt möglich wird?
     (npm install --save-dev @tsconfig/node14)

Vielleicht hat jemand mit TS-Erfahrung, die Gnade mich meiner Unwissenheit zu entledigen?

Herzlichen Dank
Kobi

@dslraser

Vielen Dank für Deine Unterstützung und den Tipp die Funktionen und Räume nicht auf der CCU, sondern in iobroker zu definieren!

In der Zwischenzeit habe ich die Funktionen und Räume im iobroker definiert und dafür gesorgt, dass nur noch die Namen meiner Homematic-Geräte von der CCU2 zum iobroker kommuniziert werden. Damit findet die Definition der für meine Progamme relevanten Datenpunkte nur noch an einem Ort im iobroker statt.

Der Grund dass der Bezeichner "battery" nach dem Neustart der Instanz hm-rega nicht
mehr vorhanden war, lag in der Tat an dem nicht kommunizierten Datenpunkt Kanal-0, wo sich der für mein Programm relevante Wert LOW_BAT befand. Dieser hatte ich in den
Einstellungen vom jeweiligen Homematic-Gerät vergessen zu aktivieren.

Da ich in meinem SmartHome-System die CCU2 nur noch als Kommunikations-Einheit
zur Funk-Übertragung der Steuerbefehle meiner Homematic-Geräte nutze und ich sämtliche JS-Skripte im iobroker erstelle und verwalte, macht es natürlich Sinn ebenfalls die Aufzählungen in iobroker zu definieren.

Bevor ich die Möglichkeiten von iobroker entdeckte, habe ich lediglich meine bestehenden Rollläden im SmartHome über die CCU2 gesteuert. im Frühling 2021 habe ich mich entschieden, weitere Homematic-Geräte in mein SmartHome zu integrieren, wobei ich den bestehenden Programmcode von der CCU2 in den iobroker migrierte, welcher auf einem RaspberryPi4 läuft.

Ich bedanke mich bei Euch für die professionelle Hilfe von @dslraser und das klärende Nachfragen von @homoran und bin dankbar, dass dieses iobroker-Forum mit solchen
qualifizierten Experten existiert.

Herzlichst
Kobi

@Homoran

Welche Informationen benötigst Du von mir?