Vorschläge zu Velux Fenstern und io-homecontrol:
https://forum.fhem.de/index.php/topic,92907.msg976733.html#msg976733
LG
pah
Habe das eben etwas umstrukturiert, und u.A. die veraltete Seite io-homecontroll schlicht in eine Weiterleitung umgewandelt (da waren ein paar at-Beispieldefinitionen drin, und sonst nicht viel...), auch die alten Verweise auf KFL200 werden auf die umbenannte neue Seite geschickt.
Ansonten habe ich erst mal alles in der Kategorie Rollladensteuerung belassen, wer Veranlassung sieht, da eine weitere Subkategorie anzulegen, darf das gerne tun, aber im Moment ist so "alles beieinander" (auch die "alten Velux"-Seiten).
Über die sollte ggf. nochmal jemand drübersehen (und löschen?), der die Teile kennt...
Wie ich mir gestern nicht anmerken lassen habe, war ich etwas überrascht, dass genau diese Dinge umgesetzt wurden, die im KLF200-Thread nicht vereinbart waren.
Nun noch ein paar konstruktive Kommentare:
- Umbenennung KLF200 -> Velux KLF200: Ich habe die Umleitung mal genauer getestet und habe keinen Fall gefunden, wo sie nicht gut funktioniert. Ich habe trotzdem die Befürchtung, dass die Umbenennung dem Google-Ranking schaden könnte. Beweise habe ich auch keine, nur die Befürchtung, dass sich die beiden Links irgendwie kannibalisieren und so die Relevanz sinkt. Man kann das ja mal drauf ankommen lassen und beobachten.
- Kategorie io-homecontrol: Ich würde diese Kategorie befürworten. Es ist ein Protokoll und andere Protokolle haben auch eine Kategorie. Dort hinein gehören die KLF200-Seite (https://wiki.fhem.de/wiki/Velux_KLF200), die alte Bastel-Seite mit den Fernbedienungen und evtl. mal was über Tahoma oder die Conexxion-Box
- Kategorie Velux: Auch diese Kategorie könnte man einführen, da kann alles mit Velux rein. Die Seite VELUX Solar-Rollladen SSL (https://wiki.fhem.de/wiki/VELUX_Solar-Rollladen_SSL) ist so wahrscheinlich noch gültig. Sie beschreibt nur nicht mehr erhältliche Hardware von Velux mit dem RTS-Protokoll. Seit Jahren wird nur noch das io-homecontrol-Protokoll verkauft. Diese Anmerkung würde ich ganz oben reinschreiben.
Viele Grüße,
Stefan.
Moin, ich habe jetzt ein paar Dinge geändert, bitte mal drüberschauen:
- Die "100-er"-Seite habe ich reanimiert, aber dann umbenannt zu dem konkreten Steuerungstyp, sie taucht dann auch unter den "Velux-Listings" bei Rollladensteuerung auf, ebenso in der dortigen Unterkategorie "io-homecontrol".
- Ob das mit Unterkategorie paßt, kann ich nicht entscheiden, grundsätzlich wäre meine Tendenz, nicht zu viele Kategorien zu schaffen, man findet sowas ja auch mit der Suchfunktion. Die Kategorien an sich sind mAn. eher nicht zum Sortieren für's Suchen geeignet, sondern dienen der logischen Gleiderung zum "Durchhangeln". Daher habe ich jetzt erst mal keine "Velux"-Kategorie aufgemacht, das ist ja auf der Rollladensteuerungs-Übersicht so schon recht präsent. Eine eigene Hauptkategorei macht m.E. dann Sinn, wenn es eine gewisse Zahl an Beiträgen gibt und/oder auch was anderes wie Rollläden damit zu steuern wären.
- Die Anmerkung zu den SSL habe ich oben hinter den "veraltet"-Hinweis gepackt und dann den Link auf die "neue" 200-er etwas näher erläutert.
Grundsätzlich kommt immer mal wieder das Problem auf, dass Seiten mal irgendwann irgendwie (durchaus sinnvoll) benannt werden, und nachträglich dann weitere Dinge dazukommen, die unter derselben Flagge segeln. Ist immer schwierig, das vorauszusehen und leider immer auch mit Nebenwirkungen verbunden, aber z.B. im Zusammenhang mit den MQTT-Themen habe ich zwischenzeitlich etwas Übung in sowas. Ich bitte daher zu entschuldigen, dass du feststellen mußtest, dass scheinbar (?) genau das "falsche" gemacht wurde.
Ich habe schon mehrfach angeregt, dem Wiki einen SMW-Aufsatz zu verpassen. Damit sind ordentliche semantische Suchen möglich, und das Thema Kategorisierung bekommt noch einen ganz anderen Stellenwert.
LG
pah
Mit io-homecontrol als Unterkategorie von Rollladensteuerung bin ich noch unglücklich. Ich hätte es unter Hardware angesiedelt.
Das Protokoll kann für alle möglichen Zwecke verwendet werden. Momentan wird es in FHEM für Rollladen, Fensteröffner und Markisen verwendet. Es sind aber auch andere Gerätekategorien spezifiziert, z.B. Garagentore, Tore, Lichtschalter, Heizungen... Auch diese Geräte würden sofort mit FHEM funktionieren.
Richtig ist aber auch, dass io-homecontrol noch sehr dünn besetzt ist.
Viele Grüße,
Stefan.
Hab io-homecontrol nach Hardware umsortiert, ist einleuchtend, wenn da auch anderes "Zeug" mit eingebunden werden kann. Kann gerne oben auf die Seite https://wiki.fhem.de/wiki/Kategorie:Io-homecontrol noch einen kurzen Hinweistext einbauen, wo man näheres dazu findet und für was es ggf. alles spezifiziert ist.
@pah: Das mit der Semantik-Funktion mag eine gute Anregung sein, aber irgendwie habe ich den Verdacht, dass es in unserem trauten Kreis hier kaum Gehör finden wird; ich habe aber auch keine Idee, wie man das so anschiebt, dass es umgesetzt ist, sollte es wirklich eine gute Idee sein...
Klingt gut.
Ich kann in einer ruhigen Minute ein paar Sätze zu io-homecontrol schreiben.
Gruß, Stefan.
Ich habe übrigens mal nachgeschaut: Google hat sich der neuen Velux KLF200 (https://wiki.fhem.de/wiki/Velux_KLF200)-Seite schon angenommen und sehr gut platziert.
Wieder was gelernt.
ZitatWieder was gelernt
;)
Damit löst sich die ganze Aufregung in Nichts auf...
LG
pah
Hi,
Ich habe soeben einen Beitrag in einem anderen Forum (https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/223 (https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/223)) gefunden:
"Is anyone still interested in the protocol used by Set&Go io? I reverse engineered the encryption. It is AES-128 encrypted with a custom block mode and padding scheme. The key for incoming and outgoing packages is the same, but the supposedly random iv used for the incoming messages seems to always be the same (a bug/poor "random" generator?). I can decrypt the messages from the logs in earlier threads and find strings such as the names and serial numbers and 16-byte keys that are likely the device/system keys. The decrypted packets also contain a CRC-16 with polynomial 8408. I wrote a small emulator to demonstrate it and uploaded it here: https://www.dropbox.com/s/laal9ylyj2n6lxe/set_go_emu.zip?dl=1 5
The sample data is from the packet logs posted long ago by leutholl and others. ( https://groups.google.com/forum/#!category-topic/openhab/AinJdyyDtG0 5 ) I was reading through their old topic on reverse engineering the protocol and felt like giving it a try. I am actually considering to buy screens and was looking for information on whether to get the RTS or io motor. I do not actually own any io devices nor the set&go mouse at the moment, so I cannot test it with actual hardware. Instead, I wrote an emulator that makes set&go io think a device is connected. To that end, I injected a .dll (VS2019) into the executable that bypasses the USB detection and reports that a device is connected on COM3. Then I wrote a Python (3.8) script to communicate on COM4 and used com0com to pipe one to the other. Now Set&Go thinks a device is connected. It finds 4 io devices from leutholl's logs, and one made-up device that seems to show a bit more UI. I don't get many settings to change (I thought that was the purpose of the set&go?) but maybe that is due to the devices that were used for the original logs.
I do not know much about the content of the messages, except that it seems to be organized in sessions and that most messages contain some kind of optional sub messages. Not all messages seem to follow this format however, this is specific to the message type.
I also had a look at the firmware. The firmware was embedded in the executable as a Qt resource. It is actually stored as 950 pre-generated and pre-encrypted protocol messages of 550 bytes, each encrypted with the same key as before. I decrypted the messages and concatenated them to get a raw firmware dump (950*512 bytes), but I do not know what instruction set is used. It looks like it is big-endian judging from a few address offsets in the beginning of the file, but that could be misleading. I can find the encryption key bytes, the firmware version, and a few text strings in the firmware image, so the dump itself looks good. From the message headers I deduced that the firmware is likely written at address 0x80008000. I'd be interested in hearing if someone knows what instruction set it is or can make any sense of it.
I did this mostly for fun, as the original topic was interesting to read and felt like a challenge. Even though quite a few years have passed, I hope it is useful to someone who wants to reverse it further. It should not be too hard to get it to a usable state if you have the corresponding hardware."
Da ich immer noch eine kostengünstigere Lösung als eine KLF200 suche: Lässt sich aus obigem Ansatz etwas machen?
VG plin
??? Das ist kein Wiki-Thema, oder?
Vielleicht machst du dazu einen separaten Thread "neben" dem Hauptthread (https://forum.fhem.de/index.php/topic,92907.0.html) auf...?
Zitat von: Beta-User am 17 September 2020, 13:00:52
??? Das ist kein Wiki-Thema, oder?
Vielleicht machst du dazu einen separaten Thread "neben" dem Hauptthread (https://forum.fhem.de/index.php/topic,92907.0.html) auf...?
a) habe übersehen, dass es im Wiki Bereich stand
b) ist neu aufgemacht [https://forum.fhem.de/index.php/topic,114290.0.html[/url]