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

[denjo]

@tombox okay schade

[tombox]

@denjo Ich habe den Interval auf Sekunden geändert und ein zusätzlichen für virtual switches eingefügt. Einfach neuinstallieren

[denjo]

@tombox super danke

[mucki]

@tombox
Vielen Dank! Das läuft nach dem ersten Kurztest super!
Der State vom virtuellen Switch wird jetzt nahezu 1:1 durchgereicht.

Ich habe jetzt noch ein persönliches Problem, da meine Blockly Kenntnisse nicht ausreichen:

Ich möchte mit dem virtuellen Smartthings Switch jetzt sozusagen eine Wechselschaltung mit einem physikalisch vorhandenen Homematic Switch realisieren.

Jetzt wird der Homematic Switch einfach mit hm-rpc.1.ID.4.STATE mit den Werten "true" und "false" geschaltet.

Bei dem virtuellen Switch durch den neuen Smartthings Adapter gibt es die Werte:

1. smartthings.0.ID.status.switch.switch.value (Werte "on" / "off" nicht beschreibbar)
2. smartthings.0.ID.capabilities.switch-off (Werte "true" / "false" zum Ausschalten)
3. smartthings.0.ID.capabilities.switch-on (Werte "true" / "false" zum Anschalten)

Problem bei 2) und 3) ist, dass a) die Werte nicht aktualisiert werden wenn "fremd" also von der Smartthings App geschaltet wird und b) es ist vollkommen egal ob der Wert auf "false" oder "true" gesetzt wird - es wird grundsätzlich Aus- bzw. Angeschaltet.

Unter diesen Umständen halte ich die Umsetzung mit einem Blockly Script, die (dauerhaft) funktioniert für ziemlich schwierig (ein Experte wird das wahrscheinlich anders sehen).

Der Oberhammer wäre, wenn du die virtuellen Switch (natürlich gerne auch andere Geräte) mit einem beschreibbaren State mit den Werten "true" und "false" zusätzlich zur Verfügung stellen könntest, der a) immer den aktuellen Wert kennt und mit true/false den Switch schalten kann.

In diesem Fall könnte man mit Blockly einfach mit dem "binde" Befehl den Homematic und den virtuellen Smartthings Schalter verheiraten.

[tombox]

@mucki Mach ich noch das die capabilities das feedback bekommen

[mucki]

@tombox
Dann wäre doch eine capability mit true/false vollkommen ausreichend, oder willst du an getrennten festhalten?

[locito09]

@tombox
Bekomme folgende error im LOG:

smartthings.0
2021-10-04 18:51:04.658	error	Error: getaddrinfo EAI_AGAIN api.smartthings.com

smartthings.0
2021-10-04 18:51:04.658	error	https://api.smartthings.com/v1/devices/44532988-9077-49ec-b855-257ee003ae9d/status

smartthings.0
2021-10-04 18:50:04.653	error	Error: getaddrinfo EAI_AGAIN api.smartthings.com

smartthings.0

Und seit Installation bekomme ich auch error im Mihome-vaccum Adapter

mihome-vacuum.0
2021-10-04 18:44:18.340	error	HTTP error when getting token cookie{"errno":"EAI_AGAIN","code":"EAI_AGAIN","syscall":"getaddrinfo","hostname":"sts.api.io.mi.com"}

[tombox]

@locito09 Ein Netzwerkproblem entweder auf deiner Seite oder bei Samsung

[locito09]

@tombox
Bei mir war vor der Installation alles OK, kann es sein das sich beide Adapter gegenseitig stören?

[tombox]

@locito09 Nein aber es liegt gerade ein weltweite Störung vor wo es auch sein kann das beide Betreiber betroffen sind

[mucki]

@tombox

Einen kleinen Fehler habe ich:
Object smartthings.0.XX.capabilities.switchLevel-setLevel is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json

[tombox]

@mucki Wann tritt der auf wen du es setzt oder beim start des adapters?

[mucki]

@tombox
Das war beim Start.

Beim Setzen kommt:
{"requestId":"XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX","error":{"code":"ConstraintViolationError","message":"The request is malformed.","details":[{"code":"UnprocessableEntityError","target":"[0].arguments.[0]","message":"invalid NUMBER type","details":[]}]}}

Bei einem Dimmer wird der Type „integer“ genutzt, richtig wäre hier wohl number:
{
"type": "state",
"common": {
"name": "",
"type": "integer",
"role": "state",
"write": true,
"read": true
},
"native": {},
"_id": "smartthings.0.X.capabilities.switchLevel-setLevel",
"acl": {
"object": 1636,
"state": 1636,
"ownerGroup": "system.group.administrator"
},
"from": "system.adapter.admin.0",
"user": "system.user.admin",
"ts": 1633610206404
}

[tombox]

@mucki Mal den ordner capabilities löschen
via github neuinstallieren und checken ob es dann geht

[mucki]

@tombox
Perfekt vielen Dank:

smartthings.0
2021-10-07 15:50:54.701 info {"results":[{"id":"X","status":"ACCEPTED"}]}

smartthings.0
2021-10-07 15:50:54.573 info {"commands":[{"capability":"switchLevel","command":"setLevel","arguments":[60]}]}

Wenn die Capatibilities jetzt noch den jeweils aktuellen State kennen würden, könnte ich ein Rudel virtueller/simulierter Switche/Thermostate/Garagentore/Rollläden auf ioBroker loslassen :-)

[denjo]

@tombox kann man eigentlich wegen mein Problem bei Samsung sowas anfragen?

[tombox]

@denjo du kannst ja mal im forum anfragen
https://community.smartthings.com

[mucki]

@tombox

Ich habe weitere "Simulated Devices" angelegt und dabei ist mir aufgefallen, dass für einige Geräte keine Capabilities für die Änderung des State zur Verfügung stehen.

Beispiel "Simulated Contact Sensor":

In diesem Fall wollte ich diverse virtuelle Kontaktsensoren von Smartthings mit real existierenden Kontaktsensoren in ioBroker verknüpfen. Kannst du hierfür auch eine Capatibiliy für den Staten (closed/open) zufügen?

Das gleiche trifft auf auf virtuelle Rauchmelder zu.

VG

[tombox]

@mucki das passiert alles automatisiert. kannst ja ml in debug setze und mir den log zusenden

[mucki]

@tombox
Sorry, habs jetzt in den Tiefen der Smartthings Community gefunden. Simulated contact sensors (und wohl wahrscheinlich auch smoke detectors) lassen sich leider nicht steuern.
Teste gerade eine Alternative auf Türbasis (auf/zu halt)....