UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Faz]

@gargano Super jetzt funktioniert es :ok_hand:
Vielen Dank für deine Ausdauer :+1:

Übrigens die resol-deltasol-mx-2xx-data.js ist in diesem Vereichnis dies wurde mit dem MyVbus
dort erzeugt.

[Gargano]

@faz na endlich. Dann war das zum Schluss noch der falsche Pfad.
Kannst Du bitte noch einen Test machen:

Nimm mal bei den Options die deviceMajorVersion raus. (Einfach auskommentieren). Ich möchte nur wissen, ob er automatisch in beiden Optimizer Files sucht.
Dann Instanz wieder neu starten.

[Faz]

@gargano sagte in Supportthread Resol-Adapter:

deviceMajorVersion

Wenn ich das auskommentiere kommen diese Fehlermeldungen:

[Gargano]

@faz das Komma auch wegnehmen :

const options1 = {
                    deviceAddress : context.deviceAddress
                }

[Faz]

@gargano sagte in Supportthread Resol-Adapter:

const options1 =

dann kommt der alte Fehler

[Gargano]

@faz ok, dann brauchen wir die Versions Info unbedingt. Muss ich mal schauen, wie ich das dann in dem Adapter allgemein gültig unterbringe. Die jetzige Lösung funktioniert, ist aber ein Hack und würde mit dem nächsten Update wieder weg sein.
Vielen Dank fürs Testen.

Schalten kannst Du auch unter Actions?

[Faz]

@gargano Ich habe zu Danken, da werde ich mal mir die Daten die wir geändert haben vorerst sichern :-)

[Gargano]

@gargano Schalten kannst Du auch unter Actions?

[Faz]

@gargano ja Funktioniert

[Gargano]

@grizzelbee Hi grizzelbee,
das war ein etwas fummeliger Act mit dem MX-Controller, da der ja 2 Dateien hat aber mit der gleichen Adresse.
Dazu muss man dann im createOptimizer die Version mit angeben.

Leider gibt der MX Controller keine Info über die Version aus. Eine Lösung wäre das in der Konfiguration wählbar zu machen.

Noch ein Punkt:
Im Main ist der Pfad für den VBus so beschrieben

const vbus = require('resol-vbus');

Das hat zur Folge das die VBus LIb im Pfad vom Resol sich befinden muss.

/opt/iobroker/node_modules/iobroker.resol/node_modules/resol-vbus

Bei einem normalen Install vom Vbus befindet sich der VBus aber hier :

/opt/iobroker/node_modules/resol-vbus

Was zur Folge hat, daß der require Pfad so aussehen muss

const vbus = require('../resol-vbus');

Ein Update vom Vbus wird auch in das Verzeichnis gemacht

/opt/iobroker/node_modules/resol-vbus

Viele Grüße

[Grizzelbee]

@gargano

Freut mich riesig, dass ihr das klären konntet.
War schon interessant so als Zuschauer am Spielfeldrand zu stehen. ;)

@Gargano schrieb:

Ich habe ein Issue bei Daniel aufgemacht, daß mit den 2 verschiedenen Adressen (32273 und 32289) ist mir unbekannt.

das war ein etwas fummeliger Act mit dem MX-Controller, da der ja 2 Dateien hat aber mit der gleichen Adresse.
Dazu muss man dann im createOptimizer die Version mit angeben.
Leider gibt der MX Controller keine Info über die Version aus. Eine Lösung wäre das in der Konfiguration wählbar zu machen.

Hmmm. In der Konfig ginge das natürlich - fände ich aber eher unelegant, weil es ja keine generelle Konfig wäre. Kontextsensitive Einstellungen, die nur bei Auswahl einer bestimmten anderen Einstellung angezeigt werden, habe ich im Broker noch nicht gesehen und auch keine Idee, wie man das realisieren könnte.
EDIT: Der FullyBrowser-Adapter macht genau das. Da könnte ich also zur Not spicken wie das geht. :)
So als Arbeitshypothese (keine Ahnung ob da etwas dran ist) - ist vielleicht die 32273 die V2 und 32289 die V1??
Dann könnte man das doch unterscheiden. Zumindest, wenn ich das Ganze Thema beim Mitlesen richtig verstanden habe.

Bei einem normalen Install vom Vbus befindet sich der VBus aber hier :

Du meinst vom myVBus Adapter?
Wenn ja - würde ich tendenziell bei der Variante:

const vbus = require('resol-vbus');

bleiben wollen, weil die Lib ja ausschließlich vom Resol Adapter verwendet wird, und für meinen Geschmack deshalb genau dorthin (/opt/iobroker/node_modules/iobroker.resol/node_modules/resol-vbus) gehört.
Zum einen um beim Löschen des Adapters auch richtig erwischt zu werden und zum anderen um sich nicht mit anderen Adaptern (hier speziell myVBus), die die selbe Lib verwenden mit der Version der Lib nicht in die Quere zu kommen. Wäre ja blöd, wenn ein Adapter eine spezielle Version einer Lib benötigt und ein anderer Adapter die plump überschreibt und damit den Adapter kaputt macht. Bei einer seltenen lib wie VBus mag das noch kein (großes) Problem sein, aber stell dir das Problem mal zum Beispiel bei Axios vor - da zerschießt ein allgemeines Update ggf. einen Großteil der Adapter.
Wenn es eine neue Version der Lib gibt, die der Adapter benötigt, wird die ja mit dem nächsten Release ausgeliefert/installiert und alles ist gut.

Wie machen wir weiter? Reichst Du einen PR mit den erarbeiteten Änderungen ein? Dann würde ich noch die Abhängigkeiten aktualisieren und ein neues Release bauen - also nachdem wir diesen V1/V2 Problem irgendwie gelöst und ggf. die Konfig angepasst haben - falls nötig.

viele Grüße
grizzelbee

[Gargano]

@grizzelbee
Da ja V1 und V2 die gleichen Adressen haben (32273) kann ich nicht auf die 32289 gehen.
Ich kontaktiere nochmal Daniel, um zu klären ob man die deviceMajorVersion aus dem MX Controller auslesen kann.
Das wäre am besten.
Falls das nicht geht, bleibt nur eine User Auswahl. Die müsste dann entweder alle Einträge vom Resol-Types anzeigen, oder nach erkennen der Adresse nur die anzeigen, die die Adresse haben. In dem Falle hieße es das die Auswahl erst nach dem Starten der Instanz angezeigt wird. Was aber z.B,. Device Watcher auch macht.
Im Fall vom MX würden dann 2 Einträge da stehen : V1 und V2, bei allen anderen nur ein Eintrag .

Ich schick Dir dann ein PR , wenn ich vom Daniel Nachricht habe.

[Grizzelbee]

@gargano

Okay. So genau habe ich nicht mitgelesen. Für mich sah das so aus als würden sich die V1 mit der Adresse 32273 und die V2 mit der Adresse 32289 beim Adapter melden.
Aus dieser Info hätte man dann die passende deviceMajorVersion ableiten und im Code setzen können.
Gibt es vielleicht irgendeine andere Info, die man auf diese Weise ausbeuten könnte? Die DeviceID vielleicht (deviceId":"007E110010" bei V2), Anzahl irgendwelcher Sensoren, Vorhandensein/Abwesenheit eines Sensors, ...?
Keine Ahnung. Ich stocher nur im Nebel, weil ich solche Konfigeinstellungen nicht sonderlich mag, weil die supportanfällig sind. Wer achtet schon auf die Hardwarerevision von irgendetwas und ahnt das das einen Unterschied an irgendeiner Stelle machen könnte? Ich sicher nicht. wenn der selbe Name drauf steht, erwarte ich, das alle Versionen identisch funktionieren.

Aber am Ende: Wenn es nichts gibt, gibt es nichts und dann muss es leider die Konfig retten.

[Gargano]

@grizzelbee sagte in Supportthread Resol-Adapter:

Für mich sah das so aus als würden sich die V1 mit der Adresse 32273 und die V2 mit der Adresse 32289 beim Adapter melden

Das wäre ja auch zu einfach :blush:

Das habe ich jetzt gesehen auf Git vom Daniel:

Known issues
The ConfigurationOptimizers do not yet detect the firmware version running on the controller to be configured. That sometimes causes configuration loads and saves to fail because unknown values are read from or written to (e.g. using the "customizer" example on a DeltaSol MX with firmware version 1.11 or below).

Short-term plans
Remove current ConfigurationOptimizer constructs in favor of RESOL's official support.

Also wenn der sowieso weg fällt und es bis jetzt nur den User faz gibt, der den MX Controller nutzt, denke ich sollte wir warten bis Daniel den Short-term plans umgesetzt hat.

[Gargano]

@grizzelbee sagte in Supportthread Resol-Adapter:

ber am Ende: Wenn es nichts gibt, gibt es nichts und dann muss es leider die Konfig retten.

Ich habe Antwort vom Daniel : Auslesen der Majorversion ist nicht möglich. Also bleibt nur die Auswahl durch den User.
Ich mach dann mal die Änderungen und schick Dir eine PR. Du müsstest dann die Auswahl einbauen.
Kannst ja schon mal schauen wie das geht und mir dann mitteilen, welche Infos in welchem Format Du brauchst. (Am Besten JSON ?)
Machen wir einen neuen Branch zum Testen ?

Viele Grüße
Werner

[Grizzelbee]

@gargano
Ich schlage vor, das ich zuerst die Konfig baue - dann kannst Du im Code darauf reagieren. Das dürfte am einfachsten sein. Das werde ich aber frühestens kommende Woche schaffen.

Ich melde mich, wenn ich soweit bin und einen Branch dafür habe.

[Grizzelbee]

@gargano

Hallo Werner,

ich finde gerade ein bisschen Zeit und Ruhe um mich um meine Projekte zu kümmern.
Bleibt es dabei, das wir das zusammen mit der Konfig-Option einbauen, oder warten wir auf das Update von Daniel (Was ziemlich lange dauern könnte, wenn ich mir seine Release-Zyklen so anschaue ;) )?

[Gargano]

@grizzelbee
Daniel hat ja gesagt, daß Major Version auslesen auch in Zukunft nicht gehen wird.
Also machen wir das mit der User Auswahl.
Ich benötige dann eine Funktion, in der ich die Auswahl reinschreiben kann (Json) und eine Funktion, die getriggert wird, wenn der User ausgewählt hat mit Rückgabewert der Auswahl oder den Index.

Viele Grüße
Werner

[Grizzelbee]

@gargano

Okay. Dann machen wir das so.

Die neue Konfig sähe dann so aus:

Auf die beiden neuen Werte kann dann über das normale Adapter-Konfig Objekt zugegriffen werden.

Passt das für dich?

[Gargano]

@grizzelbee Schaut schon gut aus. Machst Du ein Branch ?