neues Modul: G-Homa Wifi Steckdose

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

Vorheriges Thema - Nächstes Thema

Per

Ich lasse die neu angelegten Steckdosen einfach wieder löschen (notify) und dann verbindet er sich wieder mit dem alten Namen.

diepe

Hallo Zusammen,

ich hänge meine Frage einfach mal an diesen Beitrag an. Es gibt von G-Homa auch Fensterkontakte, können diese auch mit diesem Modul betrieben werden? Oder ist es möglich das Modul entsprechen zu erweitern. Denn Wifi Fensterkontakte währen schon der Hammer vor allem zu diesem Preis. Ein Versuch Fensterkontakte mit einem ESP8266 zu realisieren ist nicht so einfach.

Gruß Dieter

klausw

Das Modul ist nur für die Steckdosen ausgelegt. Wenn die Fensterkontakte mit dem selben Protokoll laufen lassen Sie sich vermutlich leicht einbauen. Wo sind sie denn erhältlich?
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

Was haben die für Batterien drin? Wifi ist nicht gerade fürs Stromsparen bekannt.

Toto1973

#424
Da ich die letzte Zeit auch das Problem habe, das mit der GHOMA-Server Steckdosen anlegt, die eigentlich schon konfiguriert waren, würde ich gerne auf iBroker umstellen.
Hat da jemand eine Anleitung, wie man das Ganze einrichtet?
Oder gibt es gar eine Möglichkeit, die Ghoma-Steckdosen über die HA-Bridge zu steuern?
Raspberry PI2, Rademacher DuoFern Stick, CUL, 2 x SCC,  JeeLink 868 Mhz, JeeLink 433 Mhz, 3x Magic UFO LED WiFi Controller, 4x MAX BC-RT-TRX-CyG, 2x MAX Fensterkontakt, 5x Rademacher Gurtwickler, 6x TX29DTH-it, 2x TX25-it als Helligkeitssensor, 1X HM-ES-PM, 6x Sonoff, 7x G-Homa, PIR-1000

Toto1973

so, ich bin jetzt soweit, das ich die Steckdosen über FHEM schalten kann. Das hat mich jetzt ein ige Stunden geksotet herauszufinden, wie man was programmiert in ioBroker :-)

Jetzt fehlt mir nur noch die Rückmeldung an FHEM, wenn man den Staus ändert!
Raspberry PI2, Rademacher DuoFern Stick, CUL, 2 x SCC,  JeeLink 868 Mhz, JeeLink 433 Mhz, 3x Magic UFO LED WiFi Controller, 4x MAX BC-RT-TRX-CyG, 2x MAX Fensterkontakt, 5x Rademacher Gurtwickler, 6x TX29DTH-it, 2x TX25-it als Helligkeitssensor, 1X HM-ES-PM, 6x Sonoff, 7x G-Homa, PIR-1000

sledge

Zitat von: Toto1973 am 09 Oktober 2019, 12:05:05
Da ich die letzte Zeit auch das Problem habe, das mit der GHOMA-Server Steckdosen anlegt, die eigentlich schon konfiguriert waren, würde ich gerne auf iBroker umstellen.
Hat da jemand eine Anleitung, wie man das Ganze einrichtet?
Oder gibt es gar eine Möglichkeit, die Ghoma-Steckdosen über die HA-Bridge zu steuern?
Klar können die Steckdosen über die HA-Bridge geschaltet werden - wie jedes FHEM-Device. Einfach über die entsprechende URL.

Hier gibt es ein Mini-Howto - weiß  nicht, ob das immer noch passt, hat aber seinerzeit gut gepasst bei mirhttps://forum.fhem.de/index.php/topic,66920.0.html.

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Toto1973

Das mit der HA-Bridge war ein Denkfehler von mir!
Ich benötige ja ein System, was mir die Steckdosen steuert.
Über IOBroker geht das jetzt sehr gut. Nur bekomme ich keine Rückmeldung, wenn ich direkt an der Steckdose schalte. Aber das muss ich nicht unbedingt haben, da ich die sowieso direkt über FHEM schalten werde.
Raspberry PI2, Rademacher DuoFern Stick, CUL, 2 x SCC,  JeeLink 868 Mhz, JeeLink 433 Mhz, 3x Magic UFO LED WiFi Controller, 4x MAX BC-RT-TRX-CyG, 2x MAX Fensterkontakt, 5x Rademacher Gurtwickler, 6x TX29DTH-it, 2x TX25-it als Helligkeitssensor, 1X HM-ES-PM, 6x Sonoff, 7x G-Homa, PIR-1000

teichtaucher

Zitat von: Per am 19 Juni 2019, 13:27:17
Ich lasse die neu angelegten Steckdosen einfach wieder löschen (notify) und dann verbindet er sich wieder mit dem alten Namen.

Ich muss das Thema nochmal aufgreifen. Bei mir legt FHEM auch immer wieder neue GHoma devices (z.B. gl.sv.GHoma_192.168.178.44_13359) an. Kannst du mal dein Notify posten mit dem du die neu angelegten Steckdosen wieder löschst?

Brandenburger

define GHoma_loeschen notify GHoma_192.* delete $NAME

Grüße aus Brandenburg

JoWiemann

Hallo,

ich habe mal ein längeres Log von GHoma Steckdosen mit Energiemessung, in dem die unknown message Einträge rausgefiltert worden sind, angefügt. Vielleicht hat ja jemand eine Idee, was die Steckdose mitteilen will.

Danke Euch Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

manu_b

Hallo liebe community.

Mein allererster Eintrag also behandelt mich bitte mit Nachsicht 😊

Ich habe insgesamt vier ghoma Steckdosen an fhem angebunden. Ea funktioniert auch alles wie es soll, allerdings habe ich ca alle zwei tage einen fhem crash. Zuletzt ist jeweils die folgende zeile im log:

2020.02.17 07:30:17 3: GHoma_Server_192.168.178.68_15645: Timer abgelaufen
Can't use an undefined value as a symbol reference at ./FHEM/53_GHoma.pm line 252


Es passiert mE dann, wenn eine Steckdose offline ist (das wlan im Keller ist nicht optimal).

Danke und Grüße
Manuel
Kann jrmand damit etwas anfangen?
Selbstbau NAS mit OMV
Ghoma, ESP2866, MQTT, Onkyo AVR, Denon AVR, fritzbox, residents
FTUI

BroPi

Da mein FHEM auch ab und zu mal crashed und GHoma der Übeltäter ist, habe ich hier mal meine Beobachtungen reingetan. Es ist eigentlich der gleiche Fakt wie oben beschrieben wurde. Immer, wenn WLAN mal kurz weg war oder Schwierigkeiten machte, stürzte FHEM komplett ab und ließ sich meist auch nicht neu starten. Hier die Infos vom Log:

2022.01.26 19:09:45 3: GHoma_94401c: Timer abgelaufen
2022.01.26 19:09:46 3: GServer_192.168.181.29_16160: Timer abgelaufen
2022.01.26 19:09:47 2: messenger set Mail_1und1 add undefiniertes Gerät UNDEFINED GHoma_93f42a GHoma 93f42a
2022.01.26 19:09:47 2: messenger set Mail_1und1 add ------
Can't use an undefined value as a symbol reference at ./FHEM/53_GHoma.pm line 252.


Lässt sich nicht im Modul dieser Fehlerfall einfach abfangen, so dass FHEM nicht abstürzt?

klausw

Zitat von: BroPi am 29 Januar 2022, 15:53:52
Da mein FHEM auch ab und zu mal crashed und GHoma der Übeltäter ist, habe ich hier mal meine Beobachtungen reingetan. Es ist eigentlich der gleiche Fakt wie oben beschrieben wurde. Immer, wenn WLAN mal kurz weg war oder Schwierigkeiten machte, stürzte FHEM komplett ab und ließ sich meist auch nicht neu starten. Hier die Infos vom Log:

2022.01.26 19:09:45 3: GHoma_94401c: Timer abgelaufen
2022.01.26 19:09:46 3: GServer_192.168.181.29_16160: Timer abgelaufen
2022.01.26 19:09:47 2: messenger set Mail_1und1 add undefiniertes Gerät UNDEFINED GHoma_93f42a GHoma 93f42a
2022.01.26 19:09:47 2: messenger set Mail_1und1 add ------
Can't use an undefined value as a symbol reference at ./FHEM/53_GHoma.pm line 252.


Lässt sich nicht im Modul dieser Fehlerfall einfach abfangen, so dass FHEM nicht abstürzt?

Wie es aussieht bricht beim neu Anlegen die Verbindung nochmal zusammen.
Ersetzt bitte mal die Zeile 252 durch
eval { syswrite( $chash->{CD}, GHoma_BuildString($init2) ); };
if ($@) {
Log3 ($thash, 3, "$thash->{TYPE} ($thash->{NAME}) syswrite error: $@\cnHash: $chash->{CD}");
return
}

das sollte zumindest den Absturz vermeiden.
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

JoWiemann

Hallo,

ich habe jetzt seit ca. 3 Wochen - aktuelles Fhem - die Situation, dass GHoma Devices aus der fhem.cfg verschwinden und ich im Web Frontend das Rote ? neben "Save config" sehe. Definiere ich das Device neu, dann ist für etwa einen Tag alles gut und es verschwindet ein anderes GHoma Device. Jemand eine Idee?

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM