neues Modul: G-Homa Wifi Steckdose

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

Vorheriges Thema - Nächstes Thema

JudgeDredd

Hallo Jostar,

erstmal vielen Dank für Deine Rückmeldung.

Zitat von: JostarBei mir sind die events auch in zeitlich unterschiedlichen Abständen.
Dann scheint es sich zumindest bei mir, um kein "abnormales" Verhalten im Sinne von defektem Gerät, zu handeln.

Zitat von: JostarWie viele events kommen, steuere ich mit dem events-on-change attribut.
Das "events-on-change"-Attribut ist ja eigentlich dafür da, weniger EVENTS zu erzeugen. Denn nur dann, wenn der neue Wert ungleich dem existierenden Wert ist.
Ich würde mir ja eher ein umgekehrtes Verhalten wünschen.

Zitat von: JostarUnd die Leistung werte ich nicht extra aus
Nunja, wozu hast Du dann eine Steckdose mit Leistungsmessung ? Hätte es da nicht auch das günstigere (sofern man in diesem Fall von günstiger reden kann) Modell getan ?

Ich würde halt gerne auf eine Leistungsmessung in FHEM reagieren. Allerdings ist das wenig zielführend, wenn ich erst 40 Minuten später mitbekomme, das ein Verbraucher aktiviert wurde oder der Verbraucher fertig ist.
Bei der HM-ES-PMSw1-Pl-DN-R1 werden die EVENTS ja auch spätestens nach 150 Sekunden erzeugt. Und das unabhängig davon, ob ein Verbraucher läuft oder nicht.
Aber ich vermute mal, hier wird deutlich, warum der Preisunterschied ggü. den HomeMatic Geräten gerechtfertigt ist.

Evtl. wende ich mich mal an die openHAB Jungs und frage mal, ob es evtl. eine Einstellung in der FirmWare der Steckdose gibt, die man mit nodejs setzen kann.

Abschließend würde mich aber noch interessieren, was das Attribut "connectInterval" bewirkt/bewirken soll
und in welcher Einheit hier gearbeitet wird.

Evtl. kann sich ja der Modul-Author (klausw) mal kurz dazu äußern.

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

Jostar

hatte ich doch geschrieben (Energie ungleich Leistung).
Readings:
cosphi 1 2018-03-20 22:32:39
current 0 2018-03-20 22:32:38
energy 2.142 2018-03-22 09:03:16
frequency 50.01 2018-03-22 08:24:31
maxpower 0.38 2018-03-22 08:59:46
power 0.38 2018-03-21 18:10:27
source local 2018-03-20 22:32:34
state on 2018-03-20 22:32:34
voltage 230.34 2018-03-22 08:59:33
Bei Statusänderung aktualisieren sich die relevanten Readings auch gleich:

cosphi 0 2018-03-22 09:18:06
current 0 2018-03-20 22:32:38
energy 2.142 2018-03-22 09:18:01
frequency 50.01 2018-03-22 08:24:31
maxpower 0 2018-03-22 09:18:06
power 0 2018-03-22 09:18:06
source remote 2018-03-22 09:17:59
state off 2018-03-22 09:17:59
voltage 230.34 2018-03-22 08:59:33

Readings werden also sowohl automatisch (in unregelmäßigen Abständen, siehe oben) aktualisiert, als auch bei Aktionen (Statuswechsel). Den Stromverbrauch würde ich nicht empfehlen über das reading "power" (Leistung, zuzüglich Zeit) zu bestimmen, sondern auf das reading "energy" (Energie) zu setzen. Für letzteres ist der zeitliche Abstand der Aktualisierung wohl nicht entscheidend. Hoffe soweit alles klar?
Raspberry Pi(s) mit FHEM auf Rasbian Jessie/Strech, DbLog/DbRep mit mySQL, piface, 1Wire-USB-Master von SMS-GUARD, RFXtrx433E

klausw

Zitat von: JudgeDredd am 22 März 2018, 07:38:00
Abschließend würde mich aber noch interessieren, was das Attribut "connectInterval" bewirkt/bewirken soll
und in welcher Einheit hier gearbeitet wird.

Evtl. kann sich ja der Modul-Author (klausw) mal kurz dazu äußern.
hatte er eigentlich...ist wohl irgendwo stecken geblieben.

connectInterval ist eine Programmierleiche genau wie connectTimeout
Das stammt noch aus der Anfangszeit des Moduls, als es als Client arbeitete (und die Dose als Server)

Zitat von: JudgeDredd am 20 März 2018, 20:35:04
Als Test habe ich mal ein TCP Paket Capture gemacht und festgestellt, das eine Kommunikation zwischen FHEM und Steckdose stattfindet.

Da wirst du wohl den Heartbeat sehen.
Im Header der 53_GHoma.pm sind die Telegramme beschrieben.

Wie oft aktualisieren die Werte denn in der GHoma App?
Falls es dort häufiger passieren sollte müsstest du nur rausfinden woran es liegt.

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

JudgeDredd

Zitat von: klauswconnectInterval ist eine Programmierleiche genau wie connectTimeout
Das stammt noch aus der Anfangszeit des Moduls, als es als Client arbeitete (und die Dose als Server)
Ups, sollte es im Thread irgendwo schon erwähnt worden sein, dann Sorry.
Aber Danke, nun weiß ich ja bescheid.

Zitat von: klauswDa wirst du wohl den Heartbeat sehen.
Das mag natürlich sein, muss ich nochmal genauer im Kabelhai anschauen.

GHoma Log:
Steckdose im Leerlauf
...
2018-03-22_14:03:46 ghoma_PwrSwitch02 energy: 0.266
2018-03-22_14:16:58 ghoma_PwrSwitch02 voltage: 232.2
2018-03-22_14:23:39 ghoma_PwrSwitch02 energy: 0.266
2018-03-22_14:24:32 ghoma_PwrSwitch02 frequency: 49.98
2018-03-22_14:29:05 ghoma_PwrSwitch02 voltage: 230.36
2018-03-22_14:31:04 ghoma_PwrSwitch02 voltage: 232.71
2018-03-22_14:43:31 ghoma_PwrSwitch02 energy: 0.266

Verbraucher angeschaltet
2018-03-22_14:51:21 ghoma_PwrSwitch02 current: 3.33
2018-03-22_14:51:21 ghoma_PwrSwitch02 power: 162.53
2018-03-22_14:51:22 ghoma_PwrSwitch02 maxpower: 774.92
2018-03-22_14:51:22 ghoma_PwrSwitch02 cosphi: 0.21

Verbraucher läuft
2018-03-22_14:52:57 ghoma_PwrSwitch02 power: 170.35
2018-03-22_14:52:57 ghoma_PwrSwitch02 cosphi: 0.22
2018-03-22_14:54:21 ghoma_PwrSwitch02 frequency: 50.01

Verbraucher ausgeschaltet
2018-03-22_15:03:17 ghoma_PwrSwitch02 current: 0
2018-03-22_15:03:17 ghoma_PwrSwitch02 power: 0
2018-03-22_15:03:17 ghoma_PwrSwitch02 maxpower: 0
2018-03-22_15:03:17 ghoma_PwrSwitch02 cosphi: 0
2018-03-22_15:03:18 ghoma_PwrSwitch02 energy: 0.3

Steckdose im Leerlauf ...
2018-03-22_15:23:11 ghoma_PwrSwitch02 energy: 0.3
2018-03-22_15:24:10 ghoma_PwrSwitch02 frequency: 49.98
2018-03-22_15:43:04 ghoma_PwrSwitch02 energy: 0.3
2018-03-22_15:54:00 ghoma_PwrSwitch02 frequency: 50
2018-03-22_16:02:51 ghoma_PwrSwitch02 energy: 0.3
...


Wie man sieht, gibt es zwischen dem anschalten (14:51:21 Uhr) eines Verbrauchers und dem ausschalten (15:03:17 Uhr)
gerade mal 3 Logeinträge. Mit Sicherheit gibt es aber während des Verbrauchs Schwankungen bei den Werten "current", "power", "energy" welche
aber kein EVENT erzeugen und somit auch nicht geloggt werden.

Zitat von: JostarDen Stromverbrauch würde ich nicht empfehlen über das reading "power" (Leistung, zuzüglich Zeit) zu bestimmen, sondern auf das reading "energy" (Energie) zu setzen
Wenn ich auf das Reading "energy" setze, dann gibt es keinen Unterschied zwischen Leerlauf und Last. Somit kann ich auch nicht sinnvoll darauf reagieren.
Mal ganz zu schweigen, dass auch während des Verbrauchs kaum EVENTS passieren (12 Minuten/3 Stück), mit denen man auf die Intensität das Verbrauchers schließen könnte.

Ich bin es von den HomeMatic Devices gewohnt, das man hier während des Verbrauchs Werte bekommt, mit denen man "arbeiten" kann.
Als Beispiel sei ein Waschtrockner angeführt, welcher im Wasch-Modus eine andere Last erzeugt als im Trockner-Modus.

Ich bin auch der Meinung, das dies nicht am Modul liegt sondern einfach an der mangelhaften Hardware.

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

CBSnake

Moin,

dann passt was bei deiner Dose nicht. :-)
Ich hab das eben mal getestet (aktuell 3 GHoma im Einsatz) eine Änderung um 17 Watt hat ca. 1 Minute gebraucht bis sie in FHEM erkannt/aktualisiert wurde. Sekundenweise wie bei ZWave oder HM wurde vermutlich das WLAN überlasten bzw FHEM zu stark blockieren.

Zwei meiner Dosen schalten nicht lastabhängig. Sie dienen nur zum schalten und zum ermitteln des Verbrauchs.
Eine Dose macht aber genau das. Diese hängt am PC, die Dose schaltet nur ab wenn maximal 8W verbraucht werden sprich der PC aus ist und das klappt sehr zuverlässig :-)

Wenn du eine WLAN-Dose mit einstellbaren Interval suchst schau dir die TPLink HS-110 (gibts auch ein Modul) an. Die hatte ich zuerst am PC. Wurde dann aber gegen die GHoma getauscht weil ich an anderer Stelle eine brauche die bei Spannungswiederkehr 100% in den Urzustand wechselt.

Grüße
Achim
FHEM auf Debian 10, HM-Wlan, JeeLink-Wlan, Wlanduino, ConBee, TP-Link Steckdose, GHoma Steckdosen, Shelly Steckdosen

Gasmast3r

Hy sagt mal hab ich das überlesen? kann es sein das die Verbrauchsmessung nicht mehr im sec takt abgefragt wird und wenn ja was müsste ich ändern ?

haneub

Hallo,
hab seit heute auch 3 Dosen, eine davon mit Leistungsmessung  ;-)
Einrichtung der 3 Dosen hat geklappt, ich sehe auch die Daten (Leistung etc), jedoch kann ich das update-interval nicht steuern.
Ich bräuchte für Lastprofile (für Verbraucher der Photovoltaik-Anlage) alle 30s einen Leistungswert (und Energie)...
Wie bekomme ich dieses? Also sowas wie ein "event-interval"
Danke für das schöne Modul, Harald

haneub

kurze Ergänzung:
Augenscheinlich wird von der Dose bei größeren Änderungen (ca. 10W?) ein neuer Event erzeugt..
Hier das Aufheizen der Kaffeemaschine:
2018-04-06_12:51:17 GH1L_P 0
2018-04-06_12:51:37 GH1L_P 1088.97
2018-04-06_12:52:47 GH1L_P 0.81
2018-04-06_12:55:57 GH1L_P 1138.13
2018-04-06_12:56:37 GH1L_P 682.72
2018-04-06_12:56:47 GH1L_P 0
Damit sollte es für meine Zwecke bereits jetzt nutzbar sein. Herzlichen Dank an die Ersteller des Moduls.

Mein Code: Lestung alle 10s, Energie alle Minute pollen aber nur dann schreiben, wenn sichs ändert. Grafik erstellen
define GH1L_P dummy
define GH1L_E dummy
define atGH1L_P at +*00:00:10 { my $d= ReadingsVal("GHoma_d3344c","power",0);; fhem("set GH1L_P $d")}
define atGH1L_E at +*00:01:00 { my $d= ReadingsVal("GHoma_d3344c","energy",0);; fhem("set GH1L_E $d")}
define FileLog_AktuellerVerbrauch FileLog ./log/AktuellerVerbrauch-%Y-%m-%d.log GH1L_P|GH1L_E
attr FileLog_AktuellerVerbrauch logtype text
attr GH1L_P event-on-change-reading state
attr GH1L_E event-on-change-reading state
attr GH1L_P room GHoma
attr GH1L_E room GHoma
attr FileLog_AktuellerVerbrauch room GHoma
define SVG_FileLog_AktuellerVerbrauch SVG FileLog_AktuellerVerbrauch:SVG_FileLog_AktuellerVerbrauch:CURRENT
attr SVG_FileLog_AktuellerVerbrauch room GHoma


klausw

Zitat von: Gasmast3r am 23 März 2018, 11:30:15
Hy sagt mal hab ich das überlesen? kann es sein das die Verbrauchsmessung nicht mehr im sec takt abgefragt wird und wenn ja was müsste ich ändern ?
Hast Du den Beitrag direkt oberhalb von Deinem gelesen?  8)

Zitat von: haneub am 05 April 2018, 23:40:50
Ich bräuchte für Lastprofile (für Verbraucher der Photovoltaik-Anlage) alle 30s einen Leistungswert (und Energie)...
Wie bekomme ich dieses? Also sowas wie ein "event-interval"
Ist in etwa die gleiche Frage...

Die Leistungsdaten werden von der Dose selbst geschickt und können (nach aktuellem Wissensstand) nicht angefordert werden.
Daher lässt sich dies vom Modul her nicht beeinflussen.
Einer der Energiemessdosenbesitzer kann mal versuchen, ob die Leistungsdaten auch geschickt werden, wenn man einer eingeschalteten Dose einfach nochmal das on Kommando schickt.

Zitat von: haneub am 06 April 2018, 14:12:20
kurze Ergänzung:
Augenscheinlich wird von der Dose bei größeren Änderungen (ca. 10W?) ein neuer Event erzeugt..

Mein Code: Lestung alle 10s, Energie alle Minute pollen aber nur dann schreiben, wenn sichs ändert. Grafik erstellen

Du könntest auch direkt deine GHoma_d3344c ins Filelog eintragen, oder was spricht dagegen?


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

CBSnake

Zitat von: klausw am 06 April 2018, 16:12:43

Einer der Energiemessdosenbesitzer kann mal versuchen, ob die Leistungsdaten auch geschickt werden, wenn man einer eingeschalteten Dose einfach nochmal das on Kommando schickt.



Leider nein ;-)

Grüße
Achim
FHEM auf Debian 10, HM-Wlan, JeeLink-Wlan, Wlanduino, ConBee, TP-Link Steckdose, GHoma Steckdosen, Shelly Steckdosen

martin-s

Zitat von: CBSnake am 06 April 2018, 16:42:57
Leider nein ;-)

Stimmt wohl.
Aber wenn man die TCP-Verbindung unterbricht werden anscheinend bei dem Reconnect alle Daten relativ zeitnah gesendet.
Wie wäre es mit einem "set GHoma_XXXX disconnect" Kommando?
Das ist vermutlich nichts um die Daten sekündlich zu aktualisieren, aber ich denke minütlich wäre durchaus ok.
Testen ob die Beobachtrung stimmt kann jeder mal in dem er das aktuelle Device löscht und dann automatisch neu anlegen lässt (vorrausgesetzt das Device wurde nicht umbenannt).

Ciao,

Martin

drdownload

Zitat von: martin-s am 29 Januar 2018, 16:14:42
Hi,

ich habe mit einer Steckdose ein Problem. Nur mit einer von 14, also vermutlich liegt es an der Steckdose selbst (wobei das die einzige Outdoor-Steckdose ist die ich im Einsatz habe), vielleicht kann man das aber trotzdem besser lösen.

Diese Steckdose scheint wohl ab und an abzustürzen. Dies hat dann zur Folge dass die Steckdose einen TCP RST auf die aktuelle Verbindung schickt und zugleich eine neue Verbindung aufbaut.

Im FHEM sieht dann das so aus dass die Steckdose auf "offline" geht und stattdessen eine neue mit IP-Adresse und Port im Namen angelegt wird, die dann aber nicht benutzbar ist.

Dies bleibt dann so bis man entweder die Steckdose aus- und wiedereinsteckt, das GHoma-Device mit IP-Adresse und Port löscht, oder vermutlich hilft es auch auf den nächsten Absturz zu warten.

Ich vermute mal im FHEM kommt die neue Verbindung an noch bevor die alte Verbindung deaktiviert wurde. Hat irgendwer eine Idee wie man das einfach beheben kann?

Ciao,

Martin

Das Problem hätte ich auch, gibt es da irgendeine Lösung?
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

DarkT

#357
Hi Leute,

ich habe das GHOMA Davice angelegt. Der Status ist initialized.
Wenn ich nun die Steckdose über den Knopf an und ausschalte, dann erhalte ich die folgenden Reading:


4cf936_source local 2018-07-12 18:00:11
4cf936_state off 2018-07-12 18:00:11

bzw.

4cf936_source local 2018-07-12 18:00:11
4cf936_state off 2018-07-12 18:00:13


Allerdings das von mir angelegte Deckdosen Device mit der MAC Adresse (AC:CF:23:4C:F9:37) der den Befehl


define st1 Ghoma 4cf937

und testweise auch mal das Device

define st2 Ghoma 4cf936


Zeigen beiden den Status:

???


Und lassen sich auch nicht schalten.

Was mache ich falsch? Das GHoma-Hauptdevice empfängt ja offensichtlich Events von der Steckdose


Habe gerade das automatisch angelegte Device gefunden. Anscheinend ist der Befehlt



defmod GHoma_4cf936 GHoma 4cf936
attr GHoma_4cf936 room Licht



Müssen die Deviceves mit Ghoma anfangen?

klausw

Zitat von: DarkT am 12 Juli 2018, 18:06:54
Müssen die Deviceves mit Ghoma anfangen?

eigentlich nicht
es wird aber nur das erste gefundene GHoma Device aktualisiert.
Lösche das automatisch angelegte und dann sollte es funktionieren (oder benenne es nach deinen Wünschen).
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

martin-s

Zitat von: drdownload am 15 Juni 2018, 13:21:47
Das Problem hätte ich auch, gibt es da irgendeine Lösung?
Ich habe einen Workaround:
Mittels:
define GHoma.at at +*00:15:00 delete GHoma_192.168.*
die hängenden Devices alle 15 Minuten löschen lassen (192.168 muss ggf. angepasst werden).
Sollte man aber nicht zu oft ausführen lassen, da, wenn alles in Ordnung ist, im Log eine Meldung:
2018.08.23 09:50:04 3: GHoma.at: Please define GHoma_192.168.* first
auftaucht