iobroker stellt keine Systemvariablen dar

[foxriver76]

@Blackmike kann man mal probieren, sollte in diesem Szenario kein Unterschied machen.

[Thomas06308]

@foxriver76 Probiere ich heute Abend mal aus, bin gerade unterwegs.

[Thomas06308]

@foxriver76 Hallo Ihr beiden,

ich habe wieder getestet. Das Script Value() statt .State() brachte keine Änderung - immer noch Invalid JSON und keine Variablenanzeige im iobroker, obwohl vorhandene Variablenwerte weiterhin aktualisiert werden.
Hab dann die CCU-Logigschicht von Modus Standard auf Kompatibilitätsmodus ungestellt und erneut getestet - absolut keine Änderung
Im HM Script Executor kommt INVALID JSON, direkt auf der CCU Script ausführen bringt Scriptausgabe4.txt
Was immer Euch hilft das Problem herauszufinden, ich teste es!

[foxriver76]

@Thomas06308 Ja, anscheinend wirft nur das initiale Skript den Fehler, das polling Skript scheint dann zu funktionieren, weshalb die States korrekt aktualisiert werden, nur das Objekt dazu fehlt, da er aus dem ersten Skript die Objekte in iob anlegen würde.

Tritt dieser Fehler: Cannot parse answer for functions ... eigentlich auch noch auf?

[Thomas06308]

@foxriver76 Ja, nach Neustart des rega-adapters tritt es auf
hm-rega.0-log.txt

[foxriver76]

@Thomas06308 Hm dann stimmt allerdings noch was net.. Kannst du das mal noch via Skript testen ausführen - villt gibt das ja noch irgendeinen Hinweis:

!# functions.fn 1.3
!#
!# Dieses Script gibt eine Liste der Gewerke als JSON String aus
!#
!# 6'2013-7'2014 bluefox, hobbyquaker
!#

object  oFunction;
string  sFunctionId;
string  sChannelId;
boolean bFirst       = true;
boolean bFirstSecond = true;

Write("{");
foreach (sFunctionId, dom.GetObject(ID_FUNCTIONS).EnumUsedIDs()) {
    if (bFirst == false) {
      WriteLine(',');
    } else {
      bFirst = false;
    }
    oFunction = dom.GetObject(sFunctionId);
	Write('"' # sFunctionId # '": ');
    Write('{"Name": "');
    WriteURL(oFunction.Name());
    Write('","TypeName":"' # oFunction.TypeName() # '_FUNCTIONS');
    Write('", "EnumInfo": "');
    WriteURL(oFunction.EnumInfo());
    Write('", "Channels": [');
	bFirstSecond = true;
    foreach(sChannelId, oFunction.EnumUsedIDs()) {
		if (bFirstSecond == false) {
		  Write(',');
		} else {
		  bFirstSecond = false;
		}
        string sIfaceId = dom.GetObject(sChannelId).Interface();
        string sIface = dom.GetObject(sIfaceId).Name();
        Write('{"Address":"' # dom.GetObject(sChannelId).Address() # '",');
        Write('"Interface":"' # sIface # '"}');
    }
    Write(']}');
}
Write('}');

[Thomas06308]

@foxriver76 Diesmal gab es keine Fehlermeldung
Sowohl im HM-Executor als auch auf der CCU unter Script testen" gab es diese Ausgabe.
Scriptausgabe5.txt

[foxriver76]

@Thomas06308 Nur da endet die Ausgabe abrupt, genau da wo dann auch etwas fehlt wenn die Daten in Rega ankommen. In Enum 1221 (Taster) kommt MEQ0046137:8, danach fehlt irgendetwas und dann kommt HUEFX001:2 das war in dem Rega Log am Anfang so - jetzt in diesem endet die Ausgabe abrupt nach MEQ0046137:8. Auf der einen Seite kann ich mir nicht vorstellen, dass die beiden Fehler zusammenhängen, auf der anderen ist es schon ein merkwürdiger Zufall..

[Thomas06308]

@foxriver76 Hmm, was würde Dir zur weiteren Analyse helfen?
Soll ich das ganze nochmal mit einer auf Werkszustand zurückgesetzten CCU testen, um eine vermurkste Konfiguration auszuschließen?

[foxriver76]

@Thomas06308 Hattest du das nicht schon gemacht? Habe Post https://forum.iobroker.net/topic/28654/iobroker-stellt-keine-systemvariablen-dar/5 so verstanden gehabt.

[Thomas06308]

@foxriver76 Hallo foxriver, ja, ich hatte sie schon resettet und im Werkszustand getestet. Inzwischen habe ich natürlich das Backup wieder eingespielt und sie läuft produktiv. Sonst gäbe es Ärger zu Hause
Was immer Dir hilft, ich teste es gern.

[foxriver76]

Wenn kein Backup eingespielt ist, wäre es zumindest interessant ob er dann die Variablen synchronisieren kann. Da es um die Anzahl Alarmmeldungen geht, die sowieso vorhanden sind, könnte man ja sehen ob es von Grund auf daran liegt.

[Thomas06308]

@foxriver76 Ich habe beide Scripte nochmal getestet, sowohl im konfigurierten als auch Werkszustand der CCU. Anbei die Ergebnisse:
scriptausgabe_variablen_ccu_werkszustand.txt
scriptausgabe_gewerke_ccu_werkszustand.txt
iobrokerlog_ccu_werkszustand.txt

scriptausgabe_variablen_ccu_konfiguriert.txt
scriptausgabe_gewerke_ccu_konfiguriert.txt
iobrokerlog_ccu_konfiguriert.txt

[Thomas06308]

@foxriver76 Habe heute mal ein nackte Raspberrymatic aufgesetzt mit Sicherhetseinstellungen "relaxed". Auch hier werden Variablen nicht zu iobroker synchronisiert. Es funktioniert also nur mit einer CCU1 mit vergleichseweise alter Firmware. Für mich sieht es so aus, als läge die Problematic im Zusammenspiel zwischen iobroker und den neueren Firmwareständen CCU2/3.
Hat jemand die Möglichkeit, mit einer CCU nochmals zu testen, ob neue Variablen synchronisiert werden?

[Glasfaser]

@Thomas06308 sagte in iobroker stellt keine Systemvariablen dar:

@foxriver76 Habe heute mal ein nackte Raspberrymatic aufgesetzt die Problematic im Zusammenspiel zwischen iobroker und den neueren Firmwareständen CCU2/3.
Hat jemand die Möglichkeit, mit einer CCU nochmals zu testen, ob neue Variablen synchronisiert werden?

Kann den Fehler nicht reproduzieren , keine Ahnung was bei dir ist .

Hier meine Einstellungen , damit du vergleichen kannst !

(Firmwareversion: 3.49.17.20191225)

[Thomas06308]

@Glasfaser Danke für Deine Unterstützung! Mein Raspberrymatic hat noch kein Funkmodul, wollte erstmal reinschnuppern bevor ich von der CCU2 umsteige.
Es hängt im gleichen Netz wie iobroker, keine Firewall dazwischen.
Meine Raspi-Firmware ist identisch zu Deiner, die Zugriffe habe ich auf Vollzugriff.
Trotzdem bekomme ich im iobroker eine Fehlermeldung.
scriptausgabe_variablen_raspberrymatic.txt

Und bei Dir werden tatsächlich auch NEU angelegte Variablen synchronisiert?

Auf meiner Produktiv-CCU konnte ich zwei Variablen identizieren, die im HM-Scriptparser zu INVALID JSON führten und diese neu parametrieren. Seitdem läuft das Script im HM-Scriptparser ohne Fehlermeldung INVALID JSON durch, iobroker meckert leider trotzdem.
Anbei noch die JSON-Ausgabe des HM-Scriptparser. Ist daran etwas auffällig?
scriptausgabe_variablen_hm-parser-20200119.txt

[Glasfaser]

@Thomas06308 sagte in iobroker stellt keine Systemvariablen dar:

@Glasfaser ,
Und bei Dir werden tatsächlich auch NEU angelegte Variablen synchronisiert?

Jipp … werden synchronisiert .

.

Stoppe mal den Adapter , lösche mal alle hm-rega Datenpunkte deinstalliere den Adapter .

Installiere den Adapter über die Katze neu .

https://github.com/ioBroker/ioBroker.hm-rega

[Blackmike]

@Thomas06308 bei dir kommt 2 mal die IseID 40 vor. Ein Parser fällt über 2 mal die gleiche Id

Black

[Thomas06308]

Zunächst vielen Dank allen, die mir geduldig bis hier geholfen haben
Neuinstallation hm-rega hat leider nicht geholfen, auch nicht die Löschung und Neusynchronisation der Objekte. Letztendlich habe ich mich schrittweise vorgetastet. Zunächst nur die Variablensynchronisation aktiviert - klappt. Dann die Programme hinzugenommen - klappt. Letztendlich funktionierte die Synchronisation überall, außer bei Gewerken.
Sobald ich die Gewerke wieder Synchronisieren lassen möchte läuft es auf "Cannot Parse..."
Vielleicht bekommen ich diese Nuss mit Eurer Hilfe auch noch geknackt?
scriptausgabe_gewerke_ccu_20200120.txt
iobrokerlog_gewerke_20200120.txt
Die Gewerke kann ich übrigens auf meiner CCU nicht bearbeiten, der Aufruf läuft in Timeout - passend zum übrigen Fehlerbild.

[Thomas06308]

GELÖST!!!
Vielen Dank nochmals an die vielen Forenmitglieder, die mir zwar nicht direkt bei der Problemlösung helfen konnten, mir aber immer wieder wichtige Hinweise gegeben haben. Ursache des Fehlers in der Gewerkesynchronisation war Datenpunkt mit "vermurkster" Bezeichnung, der einem Gewerk zugeordnet war.
Mit Hilfe des Addons HQ-UI habe ich mir alle Einträge in den Gewerken angesehen, den Übeltäter gefunden und korrigiert - und funktioniert.
Auf der CCU war der Übeltäter nicht zu finden.
Damit funktioniert nun die komplette Synchronisation wieder