- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#71
Marktplatz - Güter / Aw: [V] Adapterplatine ESP32 D...
Letzter Beitrag von frober - 13 Juni 2026, 20:55:24Zitat von: frober am 13 Juni 2026, 18:07:50Hi, mir würden 2 reichen.
PM ist unterwegs.
Ich erhöhe auf 4 Stück.
#72
Sprachsteuerung / Aw: Kann keine neuen alexa Ger...
Letzter Beitrag von passibe - 13 Juni 2026, 20:50:45Das ist echt komisch, weil das Gerät ja von alexa-fhem gefunden wird ...
Etwas komisch finde ich, dass du den Bewegungsmelder als switch hinterlegt hast; evtl. braucht der ein homebridgeMapping? Wobei es ja auch so aussieht, als würde die automatische Erkennung alles richtig erkennen ...
Welche anderen Devices sind denn noch davon betroffen? Poste vielleicht nochmal ein paar Beispiele, eventuell erkenne ich dann ein Muster.
Ansonsten, was noch helfen könnte: Wenn du set alexa reload ausführst, dann müsste im Log stehen, welche Daten an Amazon übermittelt werden. Ist recht viel JSON, aber wenn man das ein bisschen sortiert, kann man da recht gezielt nach dem problematischen device schauen und es z.B. mit dem, was bei einem funktionierenden Device passiert, abgleichen. Ein bisschen so wie ich das hier gemacht habe, um einem Problem auf die Schliche zu kommen. Wie ich gerade sehe, wenn ich mir das nochmal anschaue, meine ich mit dem JSON die "discovery response", die nach einem reload im alexa-fhem log auftauchen müsste.
Zitat von: oelidoc am 11 Juni 2026, 16:03:37[6/11/2026, 3:40:47 PM] [FHEM] Bewegungsmelder is switch
[6/11/2026, 3:40:47 PM] [FHEM] Bewegungsmelder has
[6/11/2026, 3:40:47 PM] [FHEM] Custom Voltage [voltage]
[6/11/2026, 3:40:47 PM] [FHEM] On [state;on,off]
[6/11/2026, 3:40:47 PM] [FHEM] Bewegungsmelder will not send proactive events
[6/11/2026, 3:40:47 PM] [FHEM] Bewegungsmelder uses ID: 00315EE000075A
2026-06-11 15:40:47 caching: Bewegungsmelder-voltage: 0.0
[6/11/2026, 3:40:47 PM] [FHEM] caching: Custom Voltage: 0 (as number; from '0.0')
2026-06-11 15:40:47 caching: Bewegungsmelder-state: off
Etwas komisch finde ich, dass du den Bewegungsmelder als switch hinterlegt hast; evtl. braucht der ein homebridgeMapping? Wobei es ja auch so aussieht, als würde die automatische Erkennung alles richtig erkennen ...
Welche anderen Devices sind denn noch davon betroffen? Poste vielleicht nochmal ein paar Beispiele, eventuell erkenne ich dann ein Muster.
Ansonsten, was noch helfen könnte: Wenn du set alexa reload ausführst, dann müsste im Log stehen, welche Daten an Amazon übermittelt werden. Ist recht viel JSON, aber wenn man das ein bisschen sortiert, kann man da recht gezielt nach dem problematischen device schauen und es z.B. mit dem, was bei einem funktionierenden Device passiert, abgleichen. Ein bisschen so wie ich das hier gemacht habe, um einem Problem auf die Schliche zu kommen. Wie ich gerade sehe, wenn ich mir das nochmal anschaue, meine ich mit dem JSON die "discovery response", die nach einem reload im alexa-fhem log auftauchen müsste.
#73
Sprachsteuerung / Aw: Alexa-Gerät ändern/entfern...
Letzter Beitrag von passibe - 13 Juni 2026, 20:46:14Das wurde ja hier schon diskutiert: https://forum.fhem.de/index.php?topic=139522.0
Außer es nochmal zu versuchen, mit irgendeinem LLM die Amazon-API auszuklamüsern, damit man die Geräte darüber löschen kann, fällt mir nichts ein. Bei Gary hatte es ja auch irgendwie funktioniert: https://forum.fhem.de/index.php?topic=139522.msg1342338#msg1342338
Bei mir funktioniert es nach wie vor so wie hier beschrieben: https://forum.fhem.de/index.php?topic=139522.msg1323198#msg1323198
Außer es nochmal zu versuchen, mit irgendeinem LLM die Amazon-API auszuklamüsern, damit man die Geräte darüber löschen kann, fällt mir nichts ein. Bei Gary hatte es ja auch irgendwie funktioniert: https://forum.fhem.de/index.php?topic=139522.msg1342338#msg1342338
Bei mir funktioniert es nach wie vor so wie hier beschrieben: https://forum.fhem.de/index.php?topic=139522.msg1323198#msg1323198
#74
Mobile Devices / Aw: HubForFhem
Letzter Beitrag von DLD - 13 Juni 2026, 20:40:31Hier der Link zum TestFlight für alle die mal testen wollen. Bitte gerne um Feedback.
https://testflight.apple.com/join/pWuXyeXh
https://testflight.apple.com/join/pWuXyeXh
#75
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von KölnSolar - 13 Juni 2026, 20:03:50Hi Hardy,
Doku:
Vermutlich ist das charger dann ein Doku- oder mein Interpretationsfehler
Wie gesagt, vorsichtig testen, weil ich es selber nicht kann.
Grüße Markus
Edit:
Zitatnur das nachfolgende macht leider nicht die inverse Operation!Das kann eigentlich nicht sein, da lediglich der Unterschied in 0 u. 1 besteht.
CodeAuswählen
set data_pd.dcOutCfg 0
Doku:
ZitatSet DC(USB) switch(0: off, 1: on)und müsste in "data_pd.dcOutState" sichtbar sein. Ansonsten mal das Log bei verbose=5 posten.
{
"id": 123456789,
"version": "1.0",
"sn": "R331ZEB4ZEAL0528",
"moduleType": 1,
"operateType": "dcOutCfg",
"params": {
"enabled": 0
}
}
Zitat12 V DC EIN/AUS mit "mpptCar"baue ich mal in der beigefügten Version ein.
Vermutlich ist das charger dann ein Doku- oder mein Interpretationsfehler
ZitatSet car charger switch (1: On; 0: Off)Sollte dann in data_mppt.carState sichtbar sein.
{
"id": 123456789,
"version": "1.0",
"sn": "R331ZEB4ZEAL0528",
"moduleType": 5,
"operateType": "mpptCar",
"params": {
"enabled": 1
}
}
Wie gesagt, vorsichtig testen, weil ich es selber nicht kann.
Grüße Markus
Edit:
ZitatDie App macht nur Ladeleistung in 100-er Schritten. Könnte das ein Problem werden ?Sehe ich unkritisch.
#76
Marktplatz - Güter / Aw: [V] Adapterplatine ESP32 D...
Letzter Beitrag von Wzut - 13 Juni 2026, 19:57:2910 Stück am ersten Tag .... nicht schlecht 
aber es sind noch reichlich da
aber es sind noch reichlich da
#77
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 13 Juni 2026, 19:44:08Hallo zusammen,
Urlaub geht langsam zu Ende und ich bin auf der Rückfahrt.
@300P,
ja diese Statusinformationen sind sehr wertvoll für das NN. Vor einer Implementierung müssen noch ein paar Designfragen geklärt werden.
Die WP ist in SF als Consumer eingebaut und es wird ein oder mehrere neue Schlüssel dafür benötigt.
1. Variante mit nur einem Schlüssel (z.B. opmode):
Wenn es nur einen Schüssel gibt, muß das referenzierte Reading (oder ggf. Code) genau einen der möglichen Werte
heating, defrost, hotwater, cooling, pool, poolheating
zurückgeben. Intern werden daraus binäre Informationen abgeleitet die jeden Status eindeutig kennzeichnen. Außerdem muß der Status (0|1) als Momentaufnahme auf einen Stunde integriert werden. Alles in SF ist auf eine Stunde bezogen. Einfach nur den Wert zu lesen ist nicht sinnvoll, denn wenn heating am Anfang der Stunde 1 war und am Ende der Stunde 0, bleibt 0 als Wert im Speicher. Das darf natürlich nicht sein. Aber das ist Logikimplementierung die ich leisten muß.
Vorteil der Variante ist, dass ein Schlüssel ausreicht und die Übersicht gewahrt bleibt. Nachteil besteht darin, dass nur einer der Status aktiv sein kann und z.B. heating und hotwater nicht gleichzeitig ohne besonderes zusätzlichen Parsings.
2. Variante mit separaten Schlüssel für jeden Status:
Alles oben gesagte bleibt erhalten bis auf die Tatsache, dass die Übersichtlichkeit (stark) leidet wobei verschiedene Status gleichzeitig ohne besondere Logik parallel aktiv sein können.
Ich persönlich würde die Variante 1 bevorzugen, auch wenn es eventuelle Zusatzparsings nötig werden lässt.
Die Info "compressor active" kann bereits jetzt durch den Schlüssel swstate abgebildet werden. Die Hilfe dazu werde ich anpassen um den Bezug besser herzustellen.
Die Infos "minutes since ON" und "minutes since OFF" werden so nicht erfasst, aber im Stunderaster wird der Energieverbrauch der WP erfasst. Zusammen mit der Info des Working Mode ist eine wertvolle Kombination vorhanden welche Modus wieviel an Energie in der Stunde verbraucht hat.
Nicht ganz sauber ist es wenn mehrere Status parallel existieren. Dann kann die KI aber auf die bisher bereits implementierten synthetischen Features zurückgreifen die weiterhin im System verbleiben.
Bezüglich der Modulationswerte gilt der Hinweis zur Integration des gemesssenen Wertes auf eine Stunde als Durchschnittswert. Inwieweit es hilfreich ist kommt auf einen Versuch an. Aber wahrscheinlich ist es wichtiger die Kontextwerte wie Brauchwassertemperatur Soll/Ist (deltaT zur Aufheizung) in die Environments mit einzubauen. Für einen Pool gilt dies ebenfalls. Für die Raumtemperatur haben wir bereits das Soll drin und Außentemperatur Ist. Wenn die KI diese Werte UND dazu noch die Arbeitsmodi im Training hat, sollte es für die Inferenz ebenfalls gut klappen bzw. hilfreich sein.
Nun würde mich interessieren wie du/ihr die Variante 1 gegenüber Variante 2 einschätzt.
LG,
Heiko
Urlaub geht langsam zu Ende und ich bin auf der Rückfahrt.
@300P,
ja diese Statusinformationen sind sehr wertvoll für das NN. Vor einer Implementierung müssen noch ein paar Designfragen geklärt werden.
Die WP ist in SF als Consumer eingebaut und es wird ein oder mehrere neue Schlüssel dafür benötigt.
1. Variante mit nur einem Schlüssel (z.B. opmode):
Wenn es nur einen Schüssel gibt, muß das referenzierte Reading (oder ggf. Code) genau einen der möglichen Werte
heating, defrost, hotwater, cooling, pool, poolheating
zurückgeben. Intern werden daraus binäre Informationen abgeleitet die jeden Status eindeutig kennzeichnen. Außerdem muß der Status (0|1) als Momentaufnahme auf einen Stunde integriert werden. Alles in SF ist auf eine Stunde bezogen. Einfach nur den Wert zu lesen ist nicht sinnvoll, denn wenn heating am Anfang der Stunde 1 war und am Ende der Stunde 0, bleibt 0 als Wert im Speicher. Das darf natürlich nicht sein. Aber das ist Logikimplementierung die ich leisten muß.
Vorteil der Variante ist, dass ein Schlüssel ausreicht und die Übersicht gewahrt bleibt. Nachteil besteht darin, dass nur einer der Status aktiv sein kann und z.B. heating und hotwater nicht gleichzeitig ohne besonderes zusätzlichen Parsings.
2. Variante mit separaten Schlüssel für jeden Status:
Alles oben gesagte bleibt erhalten bis auf die Tatsache, dass die Übersichtlichkeit (stark) leidet wobei verschiedene Status gleichzeitig ohne besondere Logik parallel aktiv sein können.
Ich persönlich würde die Variante 1 bevorzugen, auch wenn es eventuelle Zusatzparsings nötig werden lässt.
Die Info "compressor active" kann bereits jetzt durch den Schlüssel swstate abgebildet werden. Die Hilfe dazu werde ich anpassen um den Bezug besser herzustellen.
Die Infos "minutes since ON" und "minutes since OFF" werden so nicht erfasst, aber im Stunderaster wird der Energieverbrauch der WP erfasst. Zusammen mit der Info des Working Mode ist eine wertvolle Kombination vorhanden welche Modus wieviel an Energie in der Stunde verbraucht hat.
Nicht ganz sauber ist es wenn mehrere Status parallel existieren. Dann kann die KI aber auf die bisher bereits implementierten synthetischen Features zurückgreifen die weiterhin im System verbleiben.
Bezüglich der Modulationswerte gilt der Hinweis zur Integration des gemesssenen Wertes auf eine Stunde als Durchschnittswert. Inwieweit es hilfreich ist kommt auf einen Versuch an. Aber wahrscheinlich ist es wichtiger die Kontextwerte wie Brauchwassertemperatur Soll/Ist (deltaT zur Aufheizung) in die Environments mit einzubauen. Für einen Pool gilt dies ebenfalls. Für die Raumtemperatur haben wir bereits das Soll drin und Außentemperatur Ist. Wenn die KI diese Werte UND dazu noch die Arbeitsmodi im Training hat, sollte es für die Inferenz ebenfalls gut klappen bzw. hilfreich sein.
Nun würde mich interessieren wie du/ihr die Variante 1 gegenüber Variante 2 einschätzt.
LG,
Heiko
#78
Sprachsteuerung / Alexa-Gerät ändern/entfernen
Letzter Beitrag von Dr. Boris Neubert - 13 Juni 2026, 19:09:11Hallo,
ich bastele an einer FHEM-Integration für mein Garagentor. Das Garagentor will ich über Alexa steuern. Ich habe dazu einen Dummy angelegt mit
Weil ich dann aber einen Code zum Öffnen aufsagen muss, möchte ich lieber den genericDeviceType garage oder blind. Ich bekomme aber das Gerät in der Alexa-App weder geändert noch entfernt. Wenn ich den genericDeviceType ändere, reagiert das Gerät in der Alexa-App nicht mehr. Und wenn ich es in der Alexa-App entfernen will, kommt eine rote Warnmeldung "Alexa konnte dieses Gerät nicht entfernen. Bitte versuche es erneut."
Hat jemand einen Tipp, wie ich jetzt dieses Gerät wieder aus der Alexa-App entfernen kann?
Viele Grüße
Boris
ich bastele an einer FHEM-Integration für mein Garagentor. Das Garagentor will ich über Alexa steuern. Ich habe dazu einen Dummy angelegt mit
Code Auswählen
Attributes:
alexaName Garagentor
genericDeviceType lockDas Gerät wird in der Alexa-App erkannt, öffnen und schließen in der App sendet das Event lock unlocked bzw. lock locked.Weil ich dann aber einen Code zum Öffnen aufsagen muss, möchte ich lieber den genericDeviceType garage oder blind. Ich bekomme aber das Gerät in der Alexa-App weder geändert noch entfernt. Wenn ich den genericDeviceType ändere, reagiert das Gerät in der Alexa-App nicht mehr. Und wenn ich es in der Alexa-App entfernen will, kommt eine rote Warnmeldung "Alexa konnte dieses Gerät nicht entfernen. Bitte versuche es erneut."
Hat jemand einen Tipp, wie ich jetzt dieses Gerät wieder aus der Alexa-App entfernen kann?
Viele Grüße
Boris
#79
Marktplatz - Güter / Aw: [V] Adapterplatine ESP32 D...
Letzter Beitrag von frober - 13 Juni 2026, 18:07:50Hi, mir würden 2 reichen.
PM ist unterwegs.
PM ist unterwegs.
#80
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von bismosa - 13 Juni 2026, 18:00:59Update. Fehler (endlich) gefunden.
Ich hatte nicht mitbekommen (ich lese auch nicht die ganze Zeit mit), das das Beispiel Pumpensteuerung am 22.04. angepasst wurde:
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung
hier musste ich $name hinzufügen
Damit läuft hier schon wieder alles.
Gruß
Bismosa
@Autor 300P
Danke. Exakt. War gerade dabei die Antwort zu schreiben
Ich hatte nicht mitbekommen (ich lese auch nicht die ganze Zeit mit), das das Beispiel Pumpensteuerung am 22.04. angepasst wurde:
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung
hier musste ich $name hinzufügen
Code Auswählen
my $dt = FHEM::SolarForecast::timestringsFromOffset ($name, $startts, 0);Damit läuft hier schon wieder alles.
Gruß
Bismosa
@Autor 300P
Danke. Exakt. War gerade dabei die Antwort zu schreiben