neues Modul: G-Homa Wifi Steckdose

klausw · 03 Dezember 2015, 23:08:15

Was ist denn die FHEMRemote-App?

Depechem · 04 Dezember 2015, 07:15:36

http://www.fhemwiki.de/wiki/FHEM-Remote

Depechem · 04 Dezember 2015, 16:31:22

ich glaube ich weis an was es evtl. liegen könnte!
Scheinbar wird durch das Modul eine falsche oder komische ID für die Steckdosen erstellt!?
In der Steckdose selbst ist ja die ID: 4196 eingestellt.
Im Modul wird auch die ID eingeben (define GHoma GHoma 4196)
Beim erstellen der einzelnen Steckdosen wird dann ja keine ID-Eingabe mehr gebraucht(define LEDWand GHoma 3f0e32)
In den "Internals" der jeweiligen Steckdose wird bei der "ID" ein ">�" oder andere Symbole angegeben.
Diese komische ID hat scheinbar zur Folge das der JsonList Plugin einen Fehler erkennt und somit die App nicht arbeiten kann.

Ich hoffe ihr habt eine Idee wie man dies anders lösen könnte!?

{
"Name":"LEDWand",
"PossibleSets":"on:noArg off:noArg off-till-overnight on-till-overnight off-till on-till blink intervals off-for-timer on-for-timer toggle",
"PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment:textField-long alias eventMap userReadings:textField-long restoreOnStartup:last,on,off restoreOnReinit:last,on,off blocklocal:yes,no allowfrom connectTimeout connectInterval cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr",
"Internals": {
"DEF": "3f0e32",
"DeviceName": "3f0e32",
"FD": "18",
"IP": "192.168.2.124",
"Id": "?2",
"LASTSTATE": "off",
"MAC": "AC:CF:23:3F:0E:32",
"NAME": "LEDWand",
"NR": "24",
"PORT": "13359",
"SNAME": "GHoma",
"STATE": "off",
"TYPE": "GHoma"
},
"Readings": {
"source": { "Value":"remote", "Time":"2015-12-04 15:53:11" },
"state": { "Value":"off", "Time":"2015-12-04 15:53:11" }
},
"Attributes": {
"alias": "LED-Wand",
"room": "Alles,Wohnzimmer",
"webCmd": "on:off"
}

klausw · 04 Dezember 2015, 17:24:24

Zitat von: Depechem am 04 Dezember 2015, 16:31:22
ich glaube ich weis an was es evtl. liegen könnte!
Scheinbar wird durch das Modul eine falsche oder komische ID für die Steckdosen erstellt!?
In der Steckdose selbst ist ja die ID: 4196 eingestellt.
Im Modul wird auch die ID eingeben (define GHoma GHoma 4196)
Beim erstellen der einzelnen Steckdosen wird dann ja keine ID-Eingabe mehr gebraucht(define LEDWand GHoma 3f0e32)
In den "Internals" der jeweiligen Steckdose wird bei der "ID" ein ">�" oder andere Symbole angegeben.
Diese komische ID hat scheinbar zur Folge das der JsonList Plugin einen Fehler erkennt und somit die App nicht arbeiten kann.

Weder falsch noch komisch

Die Id liegt so vor, wie sie von der Dose gesendet wird (als Char String) Einige Zeichen können nicht dargestellt werden, da sie laut ASCII Tabelle nicht darstellbare Sonderzeichen sind. Aber wie der Name schon sagt ist es ein Internal, was vom Modul verwendet wird und meiner Meinung nach nichts in einem Frontend zu suchen hat.
Ich hatte die Id so verwendet um nicht bei jedem Heartbeat (alle 5s) die Id konvertieren zu müssen.
Das lässt sich natürlich ändern, in diesem Fall wird die Id eigentlich nicht mehr benötigt, da man sie auch aus dem DEF nehmen kann.
Lieber wäre mir natürlich, das die FHEM Remote das einfach abfängt

Depechem · 05 Dezember 2015, 07:45:28

Was kann ich nun tun damit die Dosen gut laufen, ich aber trotzdem die FHEMRemote App nutzen kann?

ftrueck · 06 Dezember 2015, 12:46:12

Hey,
coole sache dass man die GHoma Dosen auch selbst steuern kann. Gibt es irgendwo eine vollständige Protokollbeschreibung?
Ich habe in einem anderen Post zwar eine Protokollbeschreibung gefunden, aber mir fehlen noch so ein paar Dinge wie die Kommunikation ablaufen soll.

Ich habe meine Dosen als TCP Client konfiguriert die sich dann auf meinen Rechner (wo der TCP Server laufen soll) verbinden.
Ich bekomme zwar einen Connect von den Dosen, aber wenn ich den INIT senden will, reagiert die Dose nicht darauf. Scheinbar mache ich in der Kommunikation irgendwo noch Fehler. Es wäre daher Hilfreich für mich, wenn ich den FHEM Code als Referenz verwenden könnte. Kann ich den irgendwo her bekommen ohne gleich ein FHEM aufsetzen zu müssen?

Viele Grüße und Dank,
Florian

klausw · 06 Dezember 2015, 14:07:54

Zitat von: Depechem am 05 Dezember 2015, 07:45:28
Was kann ich nun tun damit die Dosen gut laufen, ich aber trotzdem die FHEMRemote App nutzen kann?

Ich könnte das Modul umschreiben, das die Id's als Klartext in den Internals auftauchen. Das wird aber etwas dauern, da ich im Mom nicht dazu komme.

Alternativ kannst du beim Entwickler der FHEMRemote App nachfragen, ob er das abfangen kann.
AndFHEM beispielsweise läuft problemlos.

Zitat von: ftrueck am 06 Dezember 2015, 12:46:12
Gibt es irgendwo eine vollständige Protokollbeschreibung?
Ich habe in einem anderen Post zwar eine Protokollbeschreibung gefunden, aber mir fehlen noch so ein paar Dinge wie die Kommunikation ablaufen soll.

Ich habe meine Dosen als TCP Client konfiguriert die sich dann auf meinen Rechner (wo der TCP Server laufen soll) verbinden.
Ich bekomme zwar einen Connect von den Dosen, aber wenn ich den INIT senden will, reagiert die Dose nicht darauf. Scheinbar mache ich in der Kommunikation irgendwo noch Fehler. Es wäre daher Hilfreich für mich, wenn ich den FHEM Code als Referenz verwenden könnte. Kann ich den irgendwo her bekommen ohne gleich ein FHEM aufsetzen zu müssen?

Hier findest du das Modul.
Am Anfang der Datei ist kurz zusammengefasst wie die Kommunikation läuft.
Die Verbindung muss offen bleiben, und der Hertbeat den die Dose alle 5s sendet beantwortet werden. Nach so 10s ohne Antwort muss ein neues Init erfolgen.

ftrueck · 07 Dezember 2015, 23:02:07

Klaus, danke für den Link zum Modul. Das hilft mir schon mal weiter.

Was genau ist eigentlich die Payload?
Bsp. Init1:

Init1 (vom Server):
# 5a a5 00 07|02 05 0d 07 05 07 12|c6 5b b5

Ist die Payload die MAC Adresse der Dose, meine eigene MAC Adresse oder etwas anderes?

Viele Grüße und Danke für Deine Geduld,
Florian

klausw · 08 Dezember 2015, 12:06:23

Zitat von: ftrueck am 07 Dezember 2015, 23:02:07
Klaus, danke für den Link zum Modul. Das hilft mir schon mal weiter.

Was genau ist eigentlich die Payload?
Bsp. Init1:

Init1 (vom Server):
# 5a a5 00 07|02 05 0d 07 05 07 12|c6 5b b5

Ist die Payload die MAC Adresse der Dose, meine eigene MAC Adresse oder etwas anderes?

Viele Grüße und Danke für Deine Geduld,
Florian

Payload [deutsch: Nutzlast] ist die eigentliche Nachricht ohne Checksumme, Längenangabe etc.

Die MAC Adresse ist von der Dose

ftrueck · 09 Dezember 2015, 11:01:01

Achso, ich verstehe, Du hast die Pipes also nur eingebaut damit wir sehen wo die Nachricht selbst steht, aber die Nachricht ist nicht variabel.
Wunderbar, das wird mir sicher helfen eine Serveranwendung zu schreiben.

Mein Ziel ist ein Standalone Server der unter Mono läuft.
So kann er sowohl unter Windows, IOS und Linux laufen, also auch auf dem Raspberry.

klausw · 09 Dezember 2015, 12:48:40

Zitat von: ftrueck am 09 Dezember 2015, 11:01:01
Achso, ich verstehe, Du hast die Pipes also nur eingebaut damit wir sehen wo die Nachricht selbst steht, aber die Nachricht ist nicht variabel.
Wunderbar, das wird mir sicher helfen eine Serveranwendung zu schreiben. Mein Ziel ist ein Standalone Server der unter Mono läuft.
So kann er sowohl unter Windows, IOS und Linux laufen, also auch auf dem Raspberry.

Ah jetzt... ich war der Meinung es Übersichtlich dokumentiert zu haben.
Ja die "|" sind nur zur besseren Übersicht.
Standalone ist sicher ressourcenschonender als in FHEM mit Perl.
Gerade der Heartbeat nervt

Da kannst du gleich noch die Lidl Steckdose die hier im Forum auch diskutiert wird einbinden

Wie soll der Zugriff auf deinen Server erfolgen?

ftrueck · 09 Dezember 2015, 16:27:12

Hey, Also mein Ziel ist es einen vergleichbaren Server wie plug.g-homa.com:4196 zu schreiben.
Die Steuerung soll über ein REST Interface (127.0.0.1:8888, oder ähnlich) möglich sein.

Momentan schlage ich mich mit den Eigenarten dieses Systems rum.

Ich kann schon die checksumme richtig berechnen, extrahiere schon die MAC der Dose und setze wohl auch schon die Nachrichten richtig zusammen, aber die Dose ist noch etwas zickig.
Ist halt etwas mühselig das Protokoll zu debuggen.

Viele Grüße,
Florian

ftrueck · 11 Dezember 2015, 13:23:16

Hallo zusammen,
ich glaube ich kann Ersten Erfolg verzeichnen. Ich habe einen (bei mir) funktionierenden standalone Server gebaut.

Die Exe findet sich im Anhang.

Was gibt es wichtiges zu wissen:
- Die Exe ist in c# geschrieben. Das bedeutet ihr braucht .net 4.0
- Der Server für die Dosen lauscht auf Port 4196
- Das WebInterface lauscht auf Port 8090
- Das WebInterface spricht JSON

Wie installiert man den Server?
- Unter windows braucht man meist nichts zu machen. Einfach starten reicht
- Unter Linux und dem Raspi muss man vorher noch mono installieren: sudo apt-get install mono-devel (achtung, dauert eine weile und braucht ettliche MB speicher)
- Die Dose muss als TcpClient konfiguriert werden. Als IP muss die jenige welche drin stehen auf der nachher die Server Anwenung läuft

Wie bedient man das Webinterface?
- ruft man das Interface über http://<ip>:8090 auf erhält man eine Übersicht der verbundenen Geräte
- ruft man http://<ip>:8090/<deviceId> auf (Das Id Feld aus der Übersicht) dann bekommt man den Einzelstatus des Geräts
- ruft man http://<ip>:8090/<deviceId>/on auf, wird das Gerät eingeschaltet. Der Aufruf dauert ca. 600 ms und man bekommt den neuen status des Geräts mitgeteilt
- ruft man http://<ip>:8090/<deviceId>/off auf, wird das Gerät ausgeschaltet. Der Aufruf dauert ca. 600 ms und man bekommt den neuen status des Geräts mitgeteilt

Gibt es Commandline Parameter?
Ja, die gibt es:
--gHomaPort=4196
--webPort=8090
--logToConsole=false
--statusDelay=500

Wird einer der Parameter nicht angegeben gilt sein Standardwert.

Tuning:
- Wenn der JSON Status beim schalten der Dose nicht stimmt, kann es daran liegen dass die Zeit Zwischen Kommando und Abfragen nicht lange genug war. In diesem Fall muss man das statusDelay erhöhen. Vorsicht: Zu hohe Werte sind evtl. kontraproduktiv.
- Das Webinterface kann man direkt in die zway UI integrieren und funktioniert zumindest bei mir soweit sehr gut.

Disclaimer:
- Die Serveranwendung ist im Experimentierstadium.
- Ich kann keinerlei Haftung für Schäden jedweder Art übernehmen. Ausprobieren auf eigene Gefahr!

Depechem · 11 Dezember 2015, 22:30:26

Zitat von: klausw am 06 Dezember 2015, 14:07:54
Ich könnte das Modul umschreiben, das die Id's als Klartext in den Internals auftauchen. Das wird aber etwas dauern, da ich im Mom nicht dazu komme.

Das wäre super wenn das irgend wie möglich wäre. Ich habe jetzt schon mehrere IOS-Apps getestet, aber die machen alle Probleme mit den Dosen!
Gib bitte eine Info wenn du etwas neues weist oder gebaut hast. Ich musste alle G-Homa Dosen entfernen damit ich FHEM mit einer IOS App nutzen kann.

Vielen Dank im voraus
Gruß Thomas

ftrueck · 13 Dezember 2015, 23:22:13

Zitat von: klausw am 04 Dezember 2015, 17:24:24
Weder falsch noch komisch
Die Id liegt so vor, wie sie von der Dose gesendet wird (als Char String) Einige Zeichen können nicht dargestellt werden, da sie laut ASCII Tabelle nicht darstellbare Sonderzeichen sind. Aber wie der Name schon sagt ist es ein Internal, was vom Modul verwendet wird und meiner Meinung nach nichts in einem Frontend zu suchen hat.
Ich hatte die Id so verwendet um nicht bei jedem Heartbeat (alle 5s) die Id konvertieren zu müssen.
Das lässt sich natürlich ändern, in diesem Fall wird die Id eigentlich nicht mehr benötigt, da man sie auch aus dem DEF nehmen kann.
Lieber wäre mir natürlich, das die FHEM Remote das einfach abfängt

Kann man in Perl daten übers Netzwerk nur als char schicken?
Ich schicke meine Daten als ByteArray übers netz, weil das die native implementierung sowohl in .NET als auch im Network Stack ist. Da ich sowieso alles über byte arrays handhaben muss, kommt die ID der Dose (Die MAC) als bytes die ich in Hex-Buchstaben umwandle. Die Hex-Zeichen sind ja (da ASCII) alle darstellbar, so dass ich da an keiner Stelle Probleme bekomme. Ich hatte es zuerst auch mal als string versucht, aber da auch mal ein \0 da drin stehen kann, ist das problematisch weil \0 auch gleichzeigt der String-Terminator ist der anzeigt wo ein String zuende ist. Grundsätzlich kann man davon ausgehen dass die wenigsten Bibliotheken ohne weiteres mit nicht-darstellbaren Zeichen zurecht kommen. Von daher würde ich evtl. empfehlen die ID ebenfalls im Perl nach hex zu konvertieren.