Hallo liebe mit-fhem-user,
nach vielen Jahren als begeisterter FHEM Anwender kann ich auch endlich mal etwas beitragen. In meinem Guthub Bereich (https://github.com/eisenfunk/24_TPLinkP100) habe ich das Modul 24_TPLinkP100 platziert. Die Beschreibung liegt als Hilfetext im Modul, als auch auf der Github Seite vor. Selbstverfreilich in DE und EN. Bitte verwendet folgende Versionen:
Version 0.3 (Initialer Upload im Github)
Für alle P100/P110/P115 bis zum 2023 Firware update mit neuer Authentifizierung.
Version 0.4 (Aktuelle Version)
Für alle P100/P110/P115 mit aktueller Firmware.
Die neue Authentifizierung schließt massive Sicherheitslücken, deswegen rate ich Euch dazu, die Dinger upzudaten. Ich selbst benutze mehrere P100/P110 und P115 und werde den Code auch weiterhin pflegen. Bitte verzeiht mir, daß ich wenig hier im Forum unterwegs bin. Ich bin nicht so der Forenmensch, deswegen reportet Bugs und Wünsche bitte im Github :)
Das Energie-Measurement ist noch nicht an die neue Authentifizierung angepasst. Das füge ich in den kommenden Tagen/Wochen (Weihnachtsstress...) hinzu.
Viel Spaß mit den günstigen WLAN Steckdosen von TP-Link und ich hoffe, daß ich helfen konnte.
lg,
Michi aka Eisenfunk
Schön, dass du etwas zurückgeben kannst.
Wenn die Steckdose in FHEM eingebunden ist, ist sie dann noch weiter über die TP-Link-App steuerbar?
Ich habe gerade gesehen, dass es die Steckdosen auch als Matterversion gibt, ich nehme an, dass diese mit deinem Modul nicht funktionieren würden.
Hast du gemessen, wie hoch der Eigenverbrauch der Steckdose ist (im on/off-Zustand).
Zitat von: Damian am 07 Dezember 2023, 18:55:18Schön, dass du etwas zurückgeben kannst.
Wenn die Steckdose in FHEM eingebunden ist, ist sie dann noch weiter über die TP-Link-App steuerbar?
Ich habe gerade gesehen, dass es die Steckdosen auch als Matterversion gibt, ich nehme an, dass diese mit deinem Modul nicht funktionieren würden.
Hast du gemessen, wie hoch der Eigenverbrauch der Steckdose ist (im on/off-Zustand).
Ja, die App geht weiterhin. Die verwende ich aber nicht, da in fhem bei mir KNX, Tapos, Homematic und und und zusammenlaeuft :)
Ob da der Eigenverbrauch dabei ist kann ich nicht sagen. TP-Link gibt keine Doku zu den Devices heraus. Aber da hilft im Zweifelsfall aufschrauben und das Messbauteil auf der Platine suchen ;-)
Mir fehlt bisher auch jede Angabe, was der Verbrauch in der JSON Rueckgabe des Devices bedeutet. Ich habe hier z.B. bei einer meiner P115 einen Rueckgabewert "current_power" von 16959 ...
Keine Ahnung ob das mA, mW, Bananen oder sonst eine SI Einheit sein soll. An der P115 haengen meine Studio Aktiv Monitore. Ich denke daher dass ~17Watt, also 16959 mW richtig sein koennte. Aber ohne eine Doku von TP-Link ist das halt nur eine Vergleichsschaetzung. Auch ob das Schein- bzw. Wirkleistung ist, ist fraglich. Aufgrund des geringen Preises halte ich die Scheinleistung fuer wahrscheinlich.
lg,
Michi
Ich meinte vielmehr, wie viel die Steckdose für sich verbraucht, wenn sie einfach in der Steckdose steckt und nichts macht, bei Tasmota ist es oft 0,8 Watt bei off und über 1 Watt bei on. Um das herauszufinden müsste man die Steckdose in ein Energiemessgerät stecken, von dem man weiß, dass es im kleinen Leistungsbereich genaue Werte liefert.
Leider habe ich kein Messgerät zum zwischenstecken. Sorry und lg
Hier mal zur Info: https://hardware-helden.de/test-smarte-wlan-steckdosen-mit-verbrauchsmessung-im-vergleich/
Hiernach verbraucht die P115/P110-Steckdose im off-Modus 0,5 Watt und im on-Modus ca. 0,9/0,8 Watt. Die Leistungsmessung ist ziemlich genau.
Kann man also nicht meckern.
Aber nun ohne provozieren zu wollen : Was ändert das jetzt an meinem Fhem Modul ?
Ein Stück weit akzeptiere ich die Stromverbrauchfragen. Aber ich baue keine WLAN schaltbaren Stecker. Auch im redaktionellen Bereich bin ich nicht, d.h. ich teste die nicht. Das hier ist ein Fhem Modul für TP Link WLAN Steckdosen und ich freue mich auf Feedback das zu einem verwertbaren Ergebnis führt, nach dem Motto: Jo, der Code sollte erweitert werden.
Meine Meinung zu Stromverbrauch ist ziemlich simpel: Entweder ich nehme die heiamtliche Grundlast zu Gunsten Basteltrieb, technischer Leidenschaft und Faulheit in Kauf ... oder ich benutze Steckdosen mit Schalter, natürlich ohne LED Zustandsanzeige. Standbyverbrauch exakt 0A.
Büdde nicht offensiv verstehen. Das ist meine Meinung und der Verbrauch der Stecker selbst interessiert mich nicht. Dir ist das wichtig, das finde ich gut und okay. Ich schreibe nur dieses Modul und will mit Standbyverbrauch nichts zu tun haben.
LG,
Michi
Zitat von: hirntot am 10 Dezember 2023, 14:51:59Aber nun ohne provozieren zu wollen : Was ändert das jetzt an meinem Fhem Modul?
Ich habe das nicht als Kritik an Deinem Modul verstanden - "nur" als Nachfrage zu technischen Details der Zwischenstecker ... also alles gut; Damian hat ja auch die Informationen selbst nachgeliefert.
Für das Modul TPLinkP100 habe ich eine Seite im Wiki (https://wiki.fhem.de/wiki/TPLinkP100) angelegt, die haupsächlich ein paar Basisinformationen sowie Links zu diesem Forenthread und deinem Github Bereich enthält.
Ich fand das Modul interessant, obwohl ich schon zig verschiedene Steckdosen in der Schublade habe.
Das Modul macht ja nur Sinn, wenn man solche Steckdosen hat oder sich gerade wegen deines Moduls welche beschafft.
Aufgrund der recherchierten Infos zum Stromverbrauch, habe ich nun eine P110 bestellt. Wäre der Stromverbrauch doppelt so hoch, würde ich sie nicht kaufen, denn dann relativiert sich schnell der Anschaffungspreis.
Sehe es positiv, ab Dienstag hast du ggf. einen potentiellen Nutzer deines Moduls, vielleicht ist es dir egal. Ich freue mich aber immer, wenn meine Module intensiv genutzt werden ;)
In der aktuellen debian-Umgebung mit einer aktuellen fhem-Version scheitert die Definition eines Devices an nicht vorhandenem Modul:
Can't locate Crypt/Random/Seed.pm in @INC (you may need to install the Crypt::Random::Seed module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 ...
Erstmal Danke für das Engagement nun auch die P100/P110 und P115 auch FHEM-fähig zu bekommen.
Ich habe von denen sogar ein paar Stück und habe diese nun angebunden.
Ich habe aus der .pm die benötigten Requirements nachgeladen:
sudo apt-get install libcryptx-perl
sudo apt-get install libdigest-sha-perl
sudo apt-get install libcrypt-random-seed-perl
sudo apt-get install libcrypt-openssl-rsa-perl
sudo apt-get install libmime-base64-urlsafe-perl
sudo apt-get install libdata-dumper-simple-perl
sudo apt-get install libcrypt-cbc-perl
Nachdem ich einige Fehler hatte, hatte ich dann noch
Crypt::CBC
Crypt::Cipher::AES
Crypt::OpenSSL::RSA
nachgeladen.
sudo apt install libcrypt-cbc-perl
sudo cpan install Crypt::Cipher::AES (leider nur als CPAN gefunden)
sudo apt install libcrypt-openssl-rsa-perl
Ein reload 24_TPLinkP100.pm und dann die devices neu angelegt.
==> und siehe da. Nun lassen sich auch P100 und P115 fhemieren :-)
Danke
Nun laufen die ersten P110 erfolgreich.
Etwas "verwundert" bin ich über die unterschiedlichen Einheiten des readings. Vielleicht könnte der Modulerstelle das bitte harmonisieren.
Wenn ich das richtig deute:
current_power : Wert / 1000 ist Watt. Also Wert 2000 sind 2 Watt ==> Anpassung im Modul direkt auf Watt, weil
today_energy : Wert entspricht Watt.
month_energy : Wert entspricht Watt.
Auch bei der Zeit scheint es Unterschiede zu geben:
on_time : Wert sind Minuten
today_runtime : Wert sind Minuten
month_runtime :Wert scheint Sekunden zu sein.
Was ist denn die Aussage von "electricity_charge" und aktuell 0 0 0 ??
Das habe ich auch in der App nicht gefunden.
Ich habe mir mal meine Logs angesehen.
Dort habe ich vom Modul nun
TapoDevice: Parsing JSON
Alle Devices funktionieren. Verbose = 0
Trotzdem bekomme ich die Meldung im log.
Welchen "Fehler" habe ich noch.
in der .om steht ja: print STDERR "TapoDevice: Parsing JSON\n";
Aber ich kann keinen Error erkennen.
Hi,
zunächst vielen Dank für die Bereitstellung des Moduls. Ich habe 4 St. P110M (Matter-Version mit Leistungsmessung) gekauft und erfolgreich eingebunden, nachdem ich die weiter oben genannten Perl-Module nachinstalliert hatte.
Die Geräte lassen sich prima über FHEM und Homebridge schalten, auch die Leistungsmessung funktioniert bisher. Allerdings bekomme ich beim Restart von FHEM folgende Fehlermeldung im log:
2024.01.18 08:55:27 1: PERL WARNING: "my" variable $reply masks earlier declaration in same scope at ./FHEM/24_TPLinkP100.pm line 542, <$fh> line 2033.
TapoDevice: Trying init() with xxx@yyy.com on 192.168.2.177
AUTH1
TapoDevice: Authenticated
2024.01.18 08:55:28 3: TPLinkP100: smartPlug_Kueche_Ambient defined.
TapoDevice: Parsing JSON
2024.01.18 08:55:28 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/24_TPLinkP100.pm line 396, <$fh> line 2033.
2024.01.18 08:55:28 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/24_TPLinkP100.pm line 397, <$fh> line 2033.
2024.01.18 08:55:28 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/24_TPLinkP100.pm line 399, <$fh> line 2033.
TapoDevice: Parsing JSON
TapoDevice: Parsing JSON erscheint auch bei mir sehr häufig im LOG.
Wenn man die Geräte mit der App schaltet dauert es teilweise mehrere Minuten, bis der Status im FHEM aktualisiert wird, obwohl interval auf 15s eingestellt ist. Das ist jetzt kein großes Problem, wäre aber schön, wenn es zuverlässig innerhalb des Invervals funktionieren würde.
Viele Grüße
Oli
Das
PERL WARNING: "my" variable $reply masks earlier declaration in same scope at ./FHEM/24_TPLinkP100.pm line 542, <$fh> line 173.
TapoDevice: Trying init()hatte ich heute auch.
Und das TapoDevice: Parsing JSON erscheint auch bei mir sehr häufig im LOG.
Da Beides zusammen mir heute das FHEM komplett lahmgelegt (und somit KEINE Daten gesammelt wurden für alle devices) hat und ich nur noch mit putty auf das System kam, habe ich das Modul wieder ausgebaut, bis es hoffentlich eine Lösung gibt.
Sehr schade.
Würde mich sehr freuen, wenn ich demnächst meine P110 wieder anschließen kann. Da ich mir auch gerade 4 weitere zum ja aktuell Super Preis bei Ama.. bestellt habe.
Ich habe mir nochmals die logs genauer angesehen und (ohne Ahnung) das 24_TPLinkP100.pm
In Zeile 542 und 544 steht tatsächlich "my $reply =" im Abschnitt (534) "sub TPLinkP100_GetUpdate ($)"
Die Fehlermeldung ist daher nachvollziehbar, wenn man get update macht.
Im Log habe ich dann aber noch den Eintrag:
FATAL: padding_depad failed: Invalid argument provided. at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pm line 20.
Vielleicht hilft die Info.
Zitat von: jnewton957 am 18 Januar 2024, 18:37:51PERL WARNING: "my" variable $reply masks earlier declaration in same scope at ./FHEM/24_TPLinkP100.pm line 542, <$fh> line 173.
TapoDevice: Trying init()
Zum einen sind das zwei Meldungen, die höchstwahrscheinlich gar nichts miteinander zu tun haben.
Und die erste Meldung ist einfach ein Hinweis auf eine unsaubere Programmierung, aber grundsätzlich kein Problem, um das man sich als Anwender Gedanken machen müsste. Funktionale Auswirkungen hat das normalerweise gar keine.
Zitat von: jnewton957 am 17 Januar 2024, 07:41:25Dort habe ich vom Modul nun
TapoDevice: Parsing JSON
Alle Devices funktionieren. Verbose = 0
Trotzdem bekomme ich die Meldung im log.
Das ist kein Fehler, das Modul ist einfach an sehr vielen Stellen an den für FHEM definierten Development-Guidelines vorbei programmiert.
Die Meldung ist einfach eine Logmeldung, die anstatt über den FHEM eigenen Log-Mechanismus lieber auf Betriebssysteme (STDERR) ausgegeben und deshalb vom FHEM-Log "eingefangen" wird.
print STDERR "TapoDevice: Parsing JSON\n";Da kannst Du in FHEM verbose level definieren, wie Du möchtest - das greift an dieser Stelle einfach nicht.
Zitat von: betateilchen am 19 Januar 2024, 21:47:15Die Meldung ist einfach eine Logmeldung, die anstatt über den FHEM eigenen Log-Mechanismus lieber auf Betriebssysteme (STDERR) ausgegeben und deshalb vom FHEM-Log "eingefangen" wird.
print STDERR "TapoDevice: Parsing JSON\n";
Da kannst Du in FHEM verbose level definieren, wie Du möchtest - das greift an dieser Stelle einfach nicht.
Vielleicht liest das ja der Modulentwickler und baut das um. QS und Standards in der Softwarentwicklung haben eben ihre Bedeutung und zeigen auch hier wieder, wie sinnvoll sie sind.
Bleibt also noch der
FATAL: padding_depad failed: Invalid argument provided. at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pm line 20.Und FATAL ist eben keine Warning :-)
Zitat von: jnewton957 am 20 Januar 2024, 13:49:32Und FATAL ist eben keine Warning
Nein, aber auch das kommt nicht aus FHEM, sondern von der Betriebssytemebene.
Den Fatal Error hatte ich bei mir noch nicht, und auch keine Abstürze. Ich habe die Codezeile mit "print SDTERR..." einfach in dem Modul auskommentiert, dann wird auch das Log nicht mehr zugespamt. Insgesamt läuft das Modul in den letzten Tagen echt stabil.
Zitat von: Bitzer am 21 Januar 2024, 12:07:57Den Fatal Error hatte ich bei mir noch nicht, und auch keine Abstürze. Ich habe die Codezeile mit "print SDTERR..." einfach in dem Modul auskommentiert, dann wird auch das Log nicht mehr zugespamt. Insgesamt läuft das Modul in den letzten Tagen echt stabil.
Hast du denn
at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pmauf deiner Raspi o.ä
bzw. sudo apt install libcrypt-cbc-perl das Modul installiert?
Evtl brauche ich das ja nicht und kann es wieder ausbauen?
Den Pfad gibt es bei mir nicht, das Modul ist allerdings installiert.
Hallo,
seit paar Tagen benutze ich das Modul auch.
Die Zeile "print STDERR "TapoDevice: Parsing JSON\n" habe ich auskommentiert,das Log bleibt sauber.
Allerdings verarbschidetet sich FHEM komplett nachts hiermit:
Can't use string ("0") as a HASH ref while "strict refs" in use at ./FHEM/24_TPLinkP100.pm line 544.
Ich habe versucht, über attr disable nachts die Steckdose und damit das Modul zu deaktivieren. Brachte nicht den Erfolg.
Ich habe jetzt mein WLAN-Zeitprogramm in Verdacht. Nachts wird abgeschaltet. Könnte sein, das die fehlende WLAN-Kennung
den Absturtz auslösst.
Ich teile das Ergebnis mit.
Tagsüber läuft alles problemlos.
Viele Grüße
Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.
Zitat von: west2107 am 29 Januar 2024, 12:21:07Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.
Das sind keine guten Nachrichten. Nun verliere ich nicht sehr häufig mein WLAN - aber garnicht ist es eben auch nicht. Ein Absturz von FHEM ist für mich sehr kritisch, da z.B. Gefrierschrank, Kühlschrank und ein paar andere Geräte wiederum von FHEM abhängen. Ganz geschweige von den vielen Statistiken, die dann wieder neu anfangen zu rechnen.
Ich hoffe mal, dass hirntot als Modulentwickler eine Idee hat, wie man das abfangen kann. Bei anderen WLAN Steckdosen-Devices führt ein Verlust vom WLAN ja nicht zum Absturz des FHEM sondern nur des entsprechenden devices.
Zitat von: jnewton957 am 29 Januar 2024, 17:33:42Zitat von: west2107 am 29 Januar 2024, 12:21:07Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.
Das sind keine guten Nachrichten. Nun verliere ich nicht sehr häufig mein WLAN - aber garnicht ist es eben auch nicht. Ein Absturz von FHEM ist für mich sehr kritisch, da z.B. Gefrierschrank, Kühlschrank und ein paar andere Geräte wiederum von FHEM abhängen. Ganz geschweige von den vielen Statistiken, die dann wieder neu anfangen zu rechnen.
Ich hoffe mal, dass hirntot als Modulentwickler eine Idee hat, wie man das abfangen kann. Bei anderen WLAN Steckdosen-Devices führt ein Verlust vom WLAN ja nicht zum Absturz des FHEM sondern nur des entsprechenden devices.
Der Modulentwickler war zuletzt am 10.12.23 online. Er scheint also hier nicht besonders aktiv zu sein.
Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.
Zitat von: Damian am 29 Januar 2024, 18:47:00Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.
... wäre schön gewesen....
Heißt du hast das Modul wieder ausgebaut oder gehst du das Risiko ein?
Ein wenig zeigt sich auch, dass eine QS der FHEM-Module dringend erforderlich ist. Denn auch das Thema mit den vielen Statusmeldungen/-logs ("print STDERR "TapoDevice: Parsing JSON\n") würde eine generelle QS sicherlich rausfiltern.
Leider bin ich kein Programmierer - sonst hätte ich ja vielleicht überlegt bei anderen Modulen das coding zu finden (kopieren/anpassen), was eben beim WLAN Abbruch das FHEM/Modul nicht abstürzen lässt.
Vielleicht schaut aber der Entwickler ja doch mal nach seinem Modul :-)
PS Ich habe die Tapo zwar laufen - aber nicht in FHEM eingebunden. Zu riskant.
Zitat von: jnewton957 am 30 Januar 2024, 10:46:54Zitat von: Damian am 29 Januar 2024, 18:47:00Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.
... wäre schön gewesen....
Heißt du hast das Modul wieder ausgebaut oder gehst du das Risiko ein?
Ein wenig zeigt sich auch, dass eine QS der FHEM-Module dringend erforderlich ist. Denn auch das Thema mit den vielen Statusmeldungen/-logs ("print STDERR "TapoDevice: Parsing JSON\n") würde eine generelle QS sicherlich rausfiltern.
Leider bin ich kein Programmierer - sonst hätte ich ja vielleicht überlegt bei anderen Modulen das coding zu finden (kopieren/anpassen), was eben beim WLAN Abbruch das FHEM/Modul nicht abstürzen lässt.
Vielleicht schaut aber der Entwickler ja doch mal nach seinem Modul :-)
PS Ich habe die Tapo zwar laufen - aber nicht in FHEM eingebunden. Zu riskant.
Ich habe es am Ende wegen der Kommentare hier gar nicht in fhem eingebunden.
Das Modul ist ja nicht offiziell eingecheckt, also darf man keine Ansprüche stellen. Und wenn der Modulentwickler keine Zeit oder Muße hat sich drum zu kümmern, dann muss man selber anpacken, mit Unzulänglichkeiten leben oder es eben nicht nutzen.
Ich habe noch von Osram (Ledvance) wifi-Steckdosen, die habe ich unter fhem auch nicht ans Laufen bekommen.
Beides funktioniert unter Home Assistant, das war schlussendlich der Auslöser mal über den Tellerrand zu schauen.
Mal schauen wie ich zukünftig zwei Systeme in Einklang bringe, vielleicht wird es aber irgendwann doch nur eins ;)
Inzwischen laufen bei mir einige Tapos in Home Assistant (HA). Per Ereignissteuerung in HA kann man sich die Werte per MQTT nach FHEM liefern, falls man das überhaupt will, denn die Visualisierung in HA ist sehr einfach realisierbar.
Zitat von: Damian am 30 Januar 2024, 11:39:36Zitat von: jnewton957 am 30 Januar 2024, 10:46:54Zitat von: Damian am 29 Januar 2024, 18:47:00Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.
... wäre schön gewesen....
Heißt du hast das Modul wieder ausgebaut oder gehst du das Risiko ein?
Ein wenig zeigt sich auch, dass eine QS der FHEM-Module dringend erforderlich ist. Denn auch das Thema mit den vielen Statusmeldungen/-logs ("print STDERR "TapoDevice: Parsing JSON\n") würde eine generelle QS sicherlich rausfiltern.
Leider bin ich kein Programmierer - sonst hätte ich ja vielleicht überlegt bei anderen Modulen das coding zu finden (kopieren/anpassen), was eben beim WLAN Abbruch das FHEM/Modul nicht abstürzen lässt.
Vielleicht schaut aber der Entwickler ja doch mal nach seinem Modul :-)
PS Ich habe die Tapo zwar laufen - aber nicht in FHEM eingebunden. Zu riskant.
Ich habe es am Ende wegen der Kommentare hier gar nicht in fhem eingebunden.
Das Modul ist ja nicht offiziell eingecheckt, also darf man keine Ansprüche stellen. Und wenn der Modulentwickler keine Zeit oder Muße hat sich drum zu kümmern, dann muss man selber anpacken, mit Unzulänglichkeiten leben oder es eben nicht nutzen.
Ich habe noch von Osram (Ledvance) wifi-Steckdosen, die habe ich unter fhem auch nicht ans Laufen bekommen.
Beides funktioniert unter Home Assistant, das war schlussendlich der Auslöser mal über den Tellerrand zu schauen.
Mal schauen wie ich zukünftig zwei Systeme in Einklang bringe, vielleicht wird es aber irgendwann doch nur eins ;)
Ich mag fhem seit langer Zeit. Deine Aussage bedeutet doch aber, es wird nicht FHEM? Sei mit Deiner Antwort ehrlich.
Zitat von: azlanw am 23 März 2024, 20:16:03Ich mag fhem seit langer Zeit. Deine Aussage bedeutet doch aber, es wird nicht FHEM? Sei mit Deiner Antwort ehrlich.
Ich habe seit paar Wochen HA daneben laufen. Nachdem ich mich mit dem System etwas intensiver beschäftig habe, musste ich feststellen, dass ein kompletter Umstieg wohl erst mal nicht stattfinden wird.
Meine persönlichen Erfahrungen:
was für einen Umstieg spricht:
+ moderne Oberfläche, ohne Aufwand auch am Handy nutzbar
+ einfache Einbindung unterstützter Hardware durch Integrationen
+ größere Community, da international
+ entwickelt sich rasant weiter
was erst mal dagegen spricht:
- fehlende Anbindung einiger Sensoren, die ich über CUL 868 MHZ bzw. Signalduino 433 MHZ im Einsatz habe
- als Entwickler stecke ich im FHEM-Code recht tief drin, so dass mir eine Problem-Umsetzung in FHEM z. Zt. leichter fällt
Ich habe mir für ein paar Sensoren MQTT-Schnittstellen definiert, so dass ich Informationen zwischen beiden Systemen austauschen kann, ohne mich für ein bestimmtes System entscheiden zu müssen. So können sich beide System erst mal ergänzen. Und da beide Systeme inzwischen in VMs laufen, brauche ich keine zusätzliche Hardware.
Was die Zukunft bringt, werden wir in ein paar Jahren sehen.
Im Anhang meine Energiedaten von heute in beiden Systemen dargestellt.