Wieder keine LAN Befehle mit 8.3.1 (Teil 2)

[Vardaaran]

Du kannst höchstens mal versuchen, deine Sonderzeichen durch URL-Codes zu ersetzen, z.b. & durch %26
Siehe hier:
https://de.wikipedia.org/wiki/Hilfe:Son ... enreferenz
VG Jürgen

Vielen Dank für die Hilfe!
Funktioniert in meinem Fall leider nicht.
Da kann ich wohl nur noch abwarten und auf einen Patch hoffen...

[jbmedia]

An dieser Stelle ein kurzes Statement, wie das Problem entstanden ist. Sobald Netzwerk-Befehle Sonderzeichen enthalten, müssen diese vom Sender codiert werden. Zu Sonderzeichen zählen vor allem : / ? # [ ] @ $ & ' ( ) * + , ; =. Der Empfänger des Befehles decodiert diese Zeichen und erhält die ursprüngliche Nachricht. Erschwerend kommt hinzu, dass die Art der Codierung vom Request-Typ (GET, POST, PUT) abhängt. Außerdem halten sich manche Geräte nicht an den Standard, z.B. die HUE Bridge bei PUT, und erwarten eine uncodierte Nachricht. Schließlich kommt noch etwas hinzu. Geht eine Nachricht über mehrere Server, muss diese u.U. vom Sender auch mehrfach codiert werden. Dies ist bei Alexa der Fall, wo der Befehl nacheinander drei Server durchläuft. Als ob das noch nicht genug wäre, macht es auch noch einen Unterschied, ob der Befehl aus der Zonen-Ansicht des Web-Interfaces, aus der Szenen-Ansicht, per IR-Fernbedienung oder über eine App wie Imperihome gesendet wird. Insgesamt ergeben sich Dutzende Varianten, einen Netzwerk-Befehl zu verschicken.

Im Großen und Ganzen funktionierten die Befehle bis zur Alexa Integration einwandfrei, wobei User Nachrichten teilweise von Hand codiert hatten, indem z.B. Leerzeichen durch %20 ersetzt wurden. Dies war eigentlich nur ein Notbehelf, der nun aber zu einem Fehler führen würde. Durch die Alexa Integration wurde die Komplexität deutlich angehoben, was uns dazu zwingt, die Codierung der Netzwerk-Befehle neu zu strukturieren. Aufgrund der Vielzahl der Befehls- und Geräte-Typen sind wir dabei auf die Hilfe der User angewiesen. Das Ganze ist verständlicherweise ärgerlich, bietet auf der anderen Seite aber die Chance, die Netzwerk-Befehle auf einen sauberen Stand zu bringen, so dass es zukünftig keine bösen Überraschungen mehr dabei gibt.

Lösung

Um das Problem zu lösen, würden wir interessierte User bitten, zunächst airStudio 8.3.4 zu installieren und die Konfiguration zu übertragen. Anschließend bitte den gewünschten Netzwerk-Befehl testen, und zwar einmal über den Test-Button in der Aktorenverwaltung, aus der Zonen-Ansicht, aus einer Szene und schließlich, sofern vorhanden, über Alexa. Das Ergebnis bitte in dieser Form posten (Beispiel):

Befehl: GET
URI: http://xxx.xxx.xxx.xxx/?...
Test: +
Zone: +
Szene: -
Alexa: +

+ bedeutet geht, - geht nicht. Bei PUT und POST käme noch die Zeile Daten dazu. Diese bitte mit dem Button </> einfügen.

Vielen Dank!

[Exciter]

Meine Ergebnisse mit 8.3.4 und Firmware 7.6
Da geht nicht viel, leider.

Ich hoffe das hilft euch weiter! Und es beweist das ich nicht nur meckere, sondern mich jederzeit gerne an der Lösung eines Problems beteilige


Befehl: GET
URI: http://192.168.178.60/ax?c1=power1 1
Test: -
Zone: -
Szene: -
Alexa: -

Befehl: GET
URI: http://192.168.178.60/cm?user=kermit&pa ... mnd=Power2 on
Test: -
Zone: -
Szene: -
Alexa: -

Befehl: PUT
URI: http://192.168.178.99/api/z64pMb1f3Kogb ... ts/1/state
Daten : {"on":true}
Test: +
Zone: +
Szene: +
Alexa: +

( Nutzernamen und Passwörter sind natürlich verändert, auch der Philips Nutzer Name.)

Edit: Beim Testen mit Alexa ist mir aufgefallen wie ungünstig es ist das zwei Geräte aus einem erzeugt werden.
Das Hue Gerät habe ich zum testen mal Gamma genannt, also gibt es ein Gamma an und ein Gamma aus.
Man muss also sagen "Schalte Gamma an an und Gamma aus aus"

So geht das doch echt nicht, oder?

[Siutsch]

Meine Ergebnisse mit 8.3.4 und Firmware 7.6


Befehl: PUT
URI: 192.168.0.13/api/xxx/groups/4/action
Daten :

Code: Alles auswählen

{
	"transitiontime" : 100,
	"on": true,
	"scene": "cXmgVfNx7O0bUrL"
}

Test: +
Zone: +
Szene: +
Alexa: nicht vorhanden


Befehl: POST
URI: api.pushover.net/1/messages.json:443
Daten :

Code: Alles auswählen

token=xxx&user=xxx&device=lg-h815,sm-g950f&title=LM_Status&message=Text&priority=0&sound=pianobar

Test: +
Zone: +
Szene: +
Alexa: nicht vorhanden


Befehl: GET
URI: 192.168.0.105/cgi-bin/hi3510/param.cgi?cmd=setioattr&-io_enable=0&-io_flag=0?usr=xxx&pwd=xxx
Test: -
Zone: -
Szene: -
Alexa: nicht vorhanden


token, user, usr, pwd und den HUE user durch xxx ersetzt, waren aber nur Buchstaben, Zahlen und ein Bindestrich (HUE), keine Sonderzeichen.


Ich meine mich zu erinnern, dass HUE zwar mit der 8.3.3 wieder funktionierte, POST für Pushover aber nicht, mit 8.3.4 nun aber auch.

Einzig GET (zur Steuerung der IPCams) klappt noch gar nicht.

Noch ne Frage:
Wenn eine Szene, gestartet über das Webinterface funktioniert, dann auch innerhalb einer Zeitsteuerung oder Funkbus-gesteuert?

[casi]

airStudio 8.34 aus diesem thread und auch FW aktualisiert:
Keine Änderung gegenüber Version 8.33

Hue Beleuchtung:
Befehl: PUT
URL: 192.168.168.99/api/ATSFdsfgrzthfjuzthekjekrklr5ma-JpRhsgdftTTr70H1ix/lights/1/state
Daten: {"on":true, "sat":223, "bri":137, "hue":36164}
Test: +
Zone: +
Szene: +
Direkt Senden: +
Alexa: deaktiviert (läuft über FHEM dummys und FHEM skill bzw. Hue skill)

Harmony Off Befehl über FHEM:
Befehl: GET
URL: user:password1234@192.168.168.98:8083/fhem?cmd.WZ.Harmony=set WZ.Harmony activity PowerOff&fwcsrf=csrf_123456789012345
Test: -
Zone: -
Szene: -
Direkt Senden: +
Alexa: deaktiviert

Da bei mir fast alles über FHEM läuft, und dies Passwort geschützt ist, ist im Befehl immer ein @ Zeichen.
Bei mir läuft also aktuell nur Hue und die direkten FS20 und IR Befehle.
Wie man sieht, ist das Einzige, was für FHEM funktioniert "Direkt Senden"

[Kat-CeDe]

Hi,

Actor 1:
Hue Beleuchtung:
Befehl: PUT
192.168.178.24/api/HvnVn5RNTjrD9PQupAHQjWlokV2sE0wShoSAaYQ2/lights/11/state
Daten: {"on":false,"transitiontime":50}
Test: +

Actor 2:
Hue Beleuchtung:
Befehl: PUT
192.168.178.24/api/HvnVn5RNTjrD9PQupAHQjWlokV2sE0wShoSAaYQ2/lights/12/state
Daten: {"on":false,"transitiontime":50}
Test: +

Szene:
Actor 1: +
Actor 2:-

Szene:
Actor 2:+
Actor 1:-

Kurz bei Hue wird nur der erste Actor in einer Szene ausgeführt. Web-Interface und Harmony verhalten sich genauso. Actoren gehen aber in Szenen nur der 1.

Ralf

[jbmedia]

Vielen Dank schon mal für das Testen! Einen wichtigen Fehler bei HTTP GET konnten wir so bereits beseitigen. Mit airStudio 8.3.5 sollten HTTP GETs also wieder funktionieren.

Aber hier bitte nur noch Testergebnisse mit 8.3.5 posten.

[jbmedia]

Kurz bei Hue wird nur der erste Actor in einer Szene ausgeführt. Web-Interface und Harmony verhalten sich genauso. Actoren gehen aber in Szenen nur der 1.

Möglicherweise ist zwischen den PUTs eine kurze Pause erforderlich, damit die HUE Bridge den Befehl an die Lampen senden kann. Die Pause bitte in der Szene einfügen. DasVerhalten müsste in früheren Versionen aber genauso gewesen sein.

[hanschris]

Hier mein Ergebnis mit 8.3.5:

Befehl: GET
URI: 192.168.178.79:8083/fhem?cmd=set chatbot message @H_S Bewegung aussen
Test: +
Zone: +
Szene: +
Alexa: nicht getestet


Befehl: GET
URI: 192.168.178.79:8083/fhem?cmd=set chatbot message @H_S Bewegung außen
Test: -
Zone: -
Szene: -
Alexa: nicht getestet

[Siutsch]

GET funktioniert wieder mit der 8.3.5

Befehl: GET
URI: 192.168.0.105/cgi-bin/hi3510/param.cgi?cmd=setioattr&-io_enable=0&-io_flag=0?usr=xxx&pwd=xxx
Test: +
Zone: nicht getestet
Szene: +
Alexa: nicht vorhanden

Super!