neues Modul: G-Homa Wifi Steckdose

Begonnen von klausw, 22 September 2015, 22:57:24

Vorheriges Thema - Nächstes Thema

Depechem

tut mir leid für meine Unwissenheit. Ich habe die Dose nun zum laufen bekommen. Sie wird mir nun automatisch im fhem also eigener Raum angezeigt. Ich habe sie umbenannt und in einen anderen Raum geschoben. Ich kann sie nun auch schalten. Nach einer Weile 5-20min verliert die Dose kurzzeitig aber irgendwie wieder die vernbindung zum fhem. Dann wird sie links wieder neu als Raum "GHoma" angezeigt und alle Einstellungen sind wieder weg. An was kann dies liegen?
Können wir die Einstellungen der GHoma Dose bitte noch mal vergleichen?
Work Mode: STA mode
Other Setting: Protocol:TCP-Client / Port ID: 4196 / Server-Address: 192..... / TCP Time Out: 30

FHEM läuft im Moment testweise auf einem Win7 Rechner
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

klausw

Die Ghoma Einstellungen passen. Du könntest den Timeout noch auf 120 setzen.
Wie benennst du die Dose um? Details.
Ist die umbenannte Dose noch vorhanden, wenn eine Neue angelegt wurde?
Wenn ja, kannst du über diese noch schalten?

Bisschen Hintergrund:
Wenn die Verbindung unterbricht (paar Sekunden reichen) Muss die Ghoma.  neu initialisiert werden. Bei diesem Vorgang wird eine neue Verbindung zu Fhem aufgebaut. Erst am Ende der Initialisierung gibt die Dose ihre Id preis. Erst jetzt wird geschaut, ob schon ein Gerät mit dieser Id existiert. Wenn ja wird diesem Gerät die Verbindung zugeordnet, wenn nein wird ein neues Gerät angelegt.

Was sein könnte ist, das du beim umbenennen die Id löschst.
Im Def unter internals muss immer die 6 stellige Id stehen.

Ich bin das ganze We unterwegs, kann also nicht selbst nachschauen...
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

KaiK

Hallo Klaus,

super! Einrichten hat einwandfrei geklappt! Danke für das Modul!

In der Referenz steht, dass man TCP-Server einstellen muss.
Dass muss m.E. TCP-Client lauten (bei TCP-Server ist auch das Server-Feld ausgegraut und nicht bearbeitbar).

VG
Kai
FHEM auf Raspberry Pi, HM-CFG-LAN, 3x HM-CC-RT-DN
Testbed: Arduino Mega 2560 mit Config. Firmata als Sensor/Aktuator

micomat

So jetzt bin ich auch endlich wieder im Lande und konnte testen :)
Funktioniert perfekt. Super Arbeit.

Die ID sieht bei mir aber etwas komisch aus: b�~

Gruß
Markus
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

klausw

Hi ihr zwei,

schön, so soll es auch sein  8)

Zitat von: KaiK am 21 November 2015, 08:48:27
In der Referenz steht, dass man TCP-Server einstellen muss.
Dass muss m.E. TCP-Client lauten (bei TCP-Server ist auch das Server-Feld ausgegraut und nicht bearbeitbar).
Stimmt, das habe ich übersehen. Werde ich korrigieren.

Zitat von: micomat am 21 November 2015, 16:22:10
Die ID sieht bei mir aber etwas komisch aus: b�~
Die soll so aussehen, oder besser gesagt ist einfach so ;)
Die Id wird so dargestellt, weil sie im Hex Format wie von der Dose gesendet abgelegt wird. (sprich die letzten 3 Stellen der MAC, die FHEM versucht als ASCII Zeichen darzustellen)
Ich habe mich dafür entschieden, weil sonst bei jedem Heartbeat (alle 5s) die ID neu berechnet werden müsste.

Klaus
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

micomat

okay :) Danke

übrigens funktioniert das bei Einstellung tcp-Server ebenfalls ;)
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

klausw

Zitat von: micomat am 21 November 2015, 22:22:04
okay :) Danke

übrigens funktioniert das bei Einstellung tcp-Server ebenfalls ;)
wie jetzt? Das kann nicht sein.
Wenn ich auf TCP Server stelle, dann meldet sich die Dose doch nicht beim FHEM da sie die IP nicht hat.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

micomat

aber fhem schickt Daten an die Dose...
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

klausw

Zitat von: micomat am 21 November 2015, 22:36:02
aber fhem schickt Daten an die Dose...
Hast du die IP im Define drin?

Ah mom kann es sein, das du noch ein altes Modul nutzt?

Es gibt ein altes das die Dose als Server nutzt: 51_GHoma.pm. dieses muss unbedingt von Hand gelöscht werden.
Das Modul was jetzt übers update kommt heisst: 53_GHoma.pm
Dort ist auch die Beschreibung korrekt. Das Modul im 1. Post ist nicht aktuell, ich hatte es vergessen zu löschen. Mach ich gleich.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

micomat

ah das erklärt das vielleicht :)
werde testen
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

Depechem

Bei mir läuft es jetzt auch super! Danke!!!!
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

Per

Habe mir auch so eine Dose zugelegt und bin mir noch nicht sicher, ob ich es bereuen muss oder nicht.
1. Musste ich die Daten mehrfach "in die Dose" speichern, damit er sie nicht vergisst (hat sich wohl aber jetzt gegeben).
2. Beim Neustart von FHEM kannte er die Dose nicht mehr, hat aber eine neue erkannt (GHoma-192.168.... oder so ähnlich), habe ich die gelöscht, kannte er plötzlich wieder die "alte". Habe mir einen Trigger zum Löschen geschrieben, seit dem tritt das aber nicht mehr auf  :o
3. Und das Schlimmste: neben den Status "on" und "off" kennt er auch "set_on" und "set_off", welche nach Belieben (also off und set_off bzw. on und set_on, aber nicht "überkreuz") sowohl aus "alten" Triggern heraus auch als beim Betätigen der webCMD aus Übersichtsseiten (Räume, Floorplan, GHoma, Detail) eingenommen werden.
In den "set_oxx"-Status läuft auch gleich noch der eventMonitor über :(.

Hier mal ein Listing von einem normalen on und einem set_off, manuell geschaltet
2015-11-27 20:49:45 GHoma GHoma_Lampe on
2015-11-27 20:49:45 GHoma GHoma_Lampe source: remote
2015-11-27 20:49:53 GHoma GHoma_Lampe set_off
2015-11-27 20:49:53 GHoma GHoma_Server 50fc4e_state: off
2015-11-27 20:49:53 GHoma GHoma_Server 50fc4e_source: remote
2015-11-27 20:49:53 GHoma GHoma_Lampe off
2015-11-27 20:49:53 GHoma GHoma_Lampe source: remote


Update habe ich erst gestern gemacht, weil ich die 53_GHoma noch gar nicht hatte.

klausw

Zitat von: Per am 27 November 2015, 20:53:59
Habe mir auch so eine Dose zugelegt und bin mir noch nicht sicher, ob ich es bereuen muss oder nicht.
1. Musste ich die Daten mehrfach "in die Dose" speichern, damit er sie nicht vergisst (hat sich wohl aber jetzt gegeben).
Möglich, habe nur 2 Dosen und bei denen hat es auf Anhieb geklappt.
Zitat von: Per am 27 November 2015, 20:53:59
2. Beim Neustart von FHEM kannte er die Dose nicht mehr, hat aber eine neue erkannt (GHoma-192.168.... oder so ähnlich), habe ich die gelöscht, kannte er plötzlich wieder die "alte". Habe mir einen Trigger zum Löschen geschrieben, seit dem tritt das aber nicht mehr auf  :o
Bei Neustart von FHEM oder Reconnect der Dose wird eine neue Verbindung aufgebaut, diese wird kurzzeitig unter GHoma:IP gespeichert, aber direkt nach Übertragung der Id Seitens der Dose wieder gelöscht. Es kann sein, das es eine Weile dauert bis es in der Übersicht verschwindet (löschen über nen Trigger kann zu Fehlern führen), aber deine sogenannte "alte" sollte weder vorher verschwunden sein noch nach dem löschen wieder auftauchen. 

Zitat von: Per am 27 November 2015, 20:53:59
3. Und das Schlimmste: neben den Status "on" und "off" kennt er auch "set_on" und "set_off", welche nach Belieben (also off und set_off bzw. on und set_on, aber nicht "überkreuz") sowohl aus "alten" Triggern heraus auch als beim Betätigen der webCMD aus Übersichtsseiten (Räume, Floorplan, GHoma, Detail) eingenommen werden.
In den "set_oxx"-Status läuft auch gleich noch der eventMonitor über :(.
set_on und set_off ist der Hinweis, das entweder on oder off angefordert wurde, aber noch nicht von der Dose quittiert wurde, mehr nicht. 50fc4e_... sind die Readings die zusätzlich im GHoma Serverdefine angezeigt werden. Da könnte man drüber diskutieren ob die sinnvoll sind.
Nur bringen 5 Meldungen pro Schaltvorgang den event Monitor nicht zum überlaufen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Per

Zitat von: klausw am 30 November 2015, 01:09:03aber deine sogenannte "alte" sollte weder vorher verschwunden sein noch nach dem löschen wieder auftauchen.
Zum Glück war die "alte" nicht weg, nur nicht ansprechbar. Vllt. habe ich nicht lange genug gewartet. Der Lösch-Trigger hat aber auch keinen Schaden angerichtet. Sollte ich die Dose beim Start einfach initialisieren (alten Status noch mal setzen)?

Zitat von: klausw am 30 November 2015, 01:09:03set_on und set_off ist der Hinweis, das entweder on oder off angefordert wurde, aber noch nicht von der Dose quittiert wurde, mehr nicht.
Aha. Das die Dose manchmal länger braucht, habe ich auch schon bemerkt.

Was ich auch bemerkte: die States sind vom Timing schlechter als das Reading:state für die Abfrage des eingebauten Buttons.
Habe das mit einem DOIF abgefragt:
define Schalter.manu DOIF ([Schalter:source] eq "local") (IF ([Schalter:state] eq "on") (set V_Schalter on) ELSE (set V_Schalter off))
Damit kann ich durch den eingebauten Schalter die lokale Steuerung übersteuern. Mittels State geht das nicht, da wird der Schalter erst wieder auf den alten Stand gesetzt, bevor er ausgewertet wird.

Achja, ich behalte sie ;).

Depechem

Hi,
die GHoma Dosen laufen zwar, aber scheinbar hat die FHEMRemote-App ein Problem wenn man mehr als eine Dose betreibt!?
Er bringt mit dann in der App einen "Json String" Fehler.
Eventuell weil der Name "GHoma" für mehere Schalter angelegt wurde!?
Wenn ich nur eine Dose definiere funktioniert es!
Hier der Auszug meiner fhem.cfg.

Kann man an den Befehlen etwas ändern damit es klappt?
---------------------------------------------
define GHoma GHoma 4196

define TerrasseLEDs GHoma 3f19b2
attr TerrasseLEDs webCmd on:off

define LEDWand GHoma 3f0e32
attr LEDWand webCmd on:off
-----------------------------------------
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...