neues Modul: G-Homa Wifi Steckdose

[klausw]

Jaja ich mach ja schon

Neue Version im SVN, der Schnelltest ergab keine Probleme

[Depechem]

Neue Version im SVN, der Schnelltest ergab keine Probleme

- "FHEMremote IOS" App bringt keinen String Fehler mehr aber angezeigt werden die Dosen in der App trotzdem noch nicht
- "FHEM IOS APP" findet die Dosen jetzt und sie können hinzugefügt werden, nur sieht man dort weder Einstellungen noch kann man sie in der App bediehnen.   

[klausw]

- "FHEMremote IOS" App bringt keinen String Fehler mehr aber angezeigt werden die Dosen in der App trotzdem noch nicht
- "FHEM IOS APP" findet die Dosen jetzt und sie können hinzugefügt werden, nur sieht man dort weder Einstellungen noch kann man sie in der App bediehnen.   

...und gerade der Schwibbogen sollte jetzt funktionieren 

Seltsam, kann es sein, der der Ios Client nur bekannte Module richtig anzeigt?
Schreibe doch den Client Ersteller an und frage nach.

state auf on oder off setzen ist eigentlich Standard.

Hast du schonmal Probiert es über readingsproxy oder dummy zu lösen?
Das ist an sich unnötig umständlich, aber vielleicht eine vorübergehende Lösung.

[Depechem]

...und gerade der Schwibbogen sollte jetzt funktionieren 

Seltsam, kann es sein, der der Ios Client nur bekannte Module richtig anzeigt?
Schreibe doch den Client Ersteller an und frage nach.

state auf on oder off setzen ist eigentlich Standard.

Hast du schonmal Probiert es über readingsproxy oder dummy zu lösen?
Das ist an sich unnötig umständlich, aber vielleicht eine vorübergehende Lösung.

ja genau Schwibbogen ist gerade wichtig 
hab schon in das "Thema: Vorstellung FHEM iOS APP" http://forum.fhem.de/index.php/topic,31733.585.html geschrieben
leider kam keine Antwort darauf 
Dummy wäre meine letze Lösung aber ist halt umständlich.
über den normalen FHEM web Zugang (Browser) werden sie ja erkannt und können geschalten werden

[klausw]

ja genau Schwibbogen ist gerade wichtig 

Daher der Dummy, bis Lichtmess ist nicht mehr so lang 

hab schon in das "Thema: Vorstellung FHEM iOS APP" http://forum.fhem.de/index.php/topic,31733.585.html geschrieben
leider kam keine Antwort darauf 
Dummy wäre meine letze Lösung aber ist halt umständlich.
über den normalen FHEM web Zugang (Browser) werden sie ja erkannt und können geschalten werden

Es geht über den Browser und auch über andFHEM.
Meiner Meinung liegt der Fehler bei der App. Evtl. kann ich etwas einbauen, das es läuft. Nur muss ich wissen was es ist...
Vielleicht gibt es auch noch alternativen, wenn der Support nicht so gut ist

[Depechem]

Meiner Meinung liegt der Fehler bei der App. Evtl. kann ich etwas einbauen, das es läuft. Nur muss ich wissen was es ist...
Vielleicht gibt es auch noch alternativen, wenn der Support nicht so gut ist

Ich Danke Dir schonmal für deine Mühe und habe dem Support der App geschrieben.
Mal sehen war dabei rauskommt.

[ftrueck]

So, mal wieder ein Update von meiner Seite aus.

Ich habe ein paar Dinge an meinem Server geändert.
Unter anderem habe ich ein paar Stellen umgeschrieben für mehr Performance, zum anderen für mehr Komfort.

Was gibt es neues:
- API Schnittstelle erweitert. Neue Kommandos hinzugefügt,
- API JSON Antwort korrigiert, so dass sie von JavaScript nun korrekt geparst werden kann,
- Übersichtliches und (hoffentlich) schönes WebInterface hinzugefügt welches auch eine API Beschreibung und eine kleine Geräte-Übersicht beinhaltet. Die Seiten sind HTML Templates, die angepasst werden können.
- Anwendung kann nun als BackgroundProcess in Linux gestartet werden. Das ging vorher nicht, weil die Anwendung auf eine Konsoleneingabe gewartet hat.

Wie kann man die Anwendung als BackgroundProcess starten?
Ich mache das so:
Putty auf den raspberry,
und dann das hier eingeben: nohup mono gHomaServer.exe > nohup.out &

Danach läuft die Anwendung bis zum nächsten Neustart im Hintergrund und man kann sich getrost wieder vom raspberry ausloggen (ssh verbindung schließen)

[ftrueck]

Um die Neugier noch etwas zu steigern, hier noch zwei screenshots.

[Per]

Habe sowohl Modul als auch Steckdose jetz seit ein paar Wochen im Einsatz.
Zwei Anmerkungen/Wünsche hätte ich dazu:
- der Server ist sehr gesprächig (wiederholt immer das vom Client), man kann ihn aber nicht mit "event-on-change-reading" regulieren.
- beim Reboot von FHEM kommt immer "source = local", was in 99% der Fälle (bei mir) nicht stimmt. Aktuell helfe ich mir (wg. der 99% und nur einem Verbraucher geht das) mit "define GHoma_init at +00:00:05 set GHoma.Lampe [GHoma.Lampe:state]" gleich nach der Definition

And now for completely different:
Als Drittes hätte ich noch eine Frage zur Arbeitsweise, weil ich gerade an einem Modul für die SOP112 arbeite: Wie bekommt das Modul aus der MAC die aktuelle IP? Gerade bei Perl ist reengineering nicht so meine starke Seite .

[ftrueck]

Hallo Per, Ich beziehe mich bei meinen Antworten auf meine Erfahrungen die ich selbst beim Entwickeln mit der Dose gemacht habe. Zum Perl Modul selbst habe ich keine weitreichenden Erfahrungen, da ich mir dieses beim Entwickeln meiner eigenen Software nicht wirklich genau angeschaut habe. Ich habe mir lediglich das Protokoll angeschaut, den Rest habe ich selbst entwickelt. Ich gehe dennoch davon aus, dass einiges auch im Perl Modul so sein wird.

Zum Thema Source = Local kann ich was sagen: Wenn Du einen reboot machst, geht die Dose in den Recovery Modus weil sie keine Antwort mehr auf den Heartbeat bekommen hat und versucht zum Server zu verbinden. Das erkennt man daran, dass sie Blinkt. Wenn dem so ist, muss sie via INIT wieder erneut initialisiert werden. Darauf hin meldet die Dose ihren Status und in diesem Status steht source = local. Das ist eine Eigenart der Dose und man kann das nur dadurch ändern dass man den letzten Status lokal speichern würde, aber dieser ist nicht sicher, da man die Dose in der Zwischenzeit auch wirklich lokal schalten könnte. Das würde dann untergehen.

Zum Thema IP: Zumindest bei meiner Variante geht im Server ein Socket Connect ein. Dieser liefert mir automatisch die IP des verbindenden mit.

Wenn ich das Perl Konstrukt nicht falsch verstehe:
Der TCP Client wird hier erstellt: $client = IO::Socket::INET->new(@opts);
Hier wird die IP einem anderen Objekt zugewiesen: $chash->{IP} = $client[1];

[klausw]

Den Ausführungen meines Vorredners habe ich eigentlich nix hinzuzufügen

Der Server ist an sich nicht gesprächig, er antwortet nur auf die Anfragen der Dose.
Das ist notwendig, da die Dose sonst in den Disconnect geht und neu initialisiert werden muss.

[Per]

Dank euch beiden für die Antworten.
Das mit dem MAC->IP ist für mich zu hoch, ich bleibe bei fixen und eingetragenen IP in meinem SOP112-Modul.
Das mit dem "localen" Status ist schade, aber nicht zu ändern. Aber dafür habe ich ja meine Lösung.

Übrigens, wenn beim Start (mind.) ein Client den Status "offline" hat (notify), schicke ich ein "delete GHoma:192.*" raus. Funktioniert gut damit.

Code Auswählen Erweitern

define GHoma_test at +00:01 IF ([GHoma.*] eq "offline") (delete GHoma:192.*)

Mit der "Gesprächigkeit" meine ich nicht die Netzlast, sondern nur die Infos auf dem Eventmonitor, die halt immer doppelt (Server UND Client) kommen.

[klausw]

Dank euch beiden für die Antworten.
Das mit dem MAC->IP ist für mich zu hoch, ich bleibe bei fixen und eingetragenen IP in meinem SOP112-Modul.
Das mit dem "localen" Status ist schade, aber nicht zu ändern. Aber dafür habe ich ja meine Lösung.

Die IP wird von der Bibliothek IO::Socket::INET übergeben sobald ein neuer Port geöffnet wird.

Mit der "Gesprächigkeit" meine ich nicht die Netzlast, sondern nur die Infos auf dem Eventmonitor, die halt immer doppelt (Server UND Client) kommen.

Im EventMonitor kommt bei mir keine Info zum Heartbeat, komisch

[Per]

Ich glaube, wir reden aneinander vorbei .

Beispiel:

Code Auswählen Erweitern

2015-12-29 22:28:52 GHoma GHoma_Server 50fc4e_state: on
2015-12-29 22:28:52 GHoma GHoma_Server 50fc4e_source: local
2015-12-29 22:28:52 GHoma GHoma_Lampe on
2015-12-29 22:28:52 GHoma GHoma_Lampe source: local

[satprofi]

Hallo.
Heute auch im Bauhaus diese Steckdoesen entdeckt. Goggle spuckt auch Conrad als Vertreiber aus, unglaublich das die noch nicht beworben wurden.
Kosten zwar ~ 35.- /Stk. , ob da nicht gleich eine Homematic günstiger kommt?
Oder gibts Vorteile bei diesen Dingern?

gruss