- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
MQTT / Aw: shelly dimmer gen 3
Letzter Beitrag von GeZi3560 - 19 Mai 2026, 11:45:11Meiner läuft hiermit:
Code Auswählen
defmod MediaDeckenlampe Shelly 192.168.3.166
attr MediaDeckenlampe DbLogExclude .*
attr MediaDeckenlampe alias EG Mediaroom Deckenmlampe IP166
attr MediaDeckenlampe devStateIcon {my $onl = ReadingsVal($name,'network_connection','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; my $light = FW_makeImage(ReadingsVal($name,'state','off'));; my $temp = ReadingsVal($name,'inttemp','-100');; my $ip = ReadingsVal($name,'ip','none');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MediaDeckenlampe group Licht
attr MediaDeckenlampe icon li_wht_on
attr MediaDeckenlampe model shellyprodm1pm
attr MediaDeckenlampe room Mediaroom
attr MediaDeckenlampe webCmd pct:on:off #12
Anfängerfragen / Aw: Die Leistun eines Hoymiles...
Letzter Beitrag von boeho - 19 Mai 2026, 10:45:45Danke für den Tip, bin erst am Wochenende wieder zu Hause und melde mich dann.
Was wäre denn besser wget oder POST ?
VG
Was wäre denn besser wget oder POST ?
VG
#13
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 19 Mai 2026, 10:29:20Danke für deine Rückmeldung Wolle02. Auch das sieht einwandfrei aus.
#14
Sprachsteuerung / Aw: HomebridgeMapping korrektu...
Letzter Beitrag von Wolfpunk - 19 Mai 2026, 10:12:49Stimmt, du hast "stopped" in deiner setList:
Code Auswählen
setList open closed opening closing stopped #15
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Wolle02 - 19 Mai 2026, 10:11:28Hallo zusammen, auch mal eine Rückmeldung von mir. Ich bin auch sehr zufrieden mit der aktuellen Situation. Im Bild meine aktuelle Prognose und die Realität von heute vormittag. Ich denke mit den Werten kann man zufrieden sein.
Ich verwende die Einstellung v1_common_pv
Ich verwende die Einstellung v1_common_pv
#16
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von vbs - 19 Mai 2026, 10:00:35Zitat von: pc1246 am 14 Mai 2026, 21:58:01Die Variante von Rippi in https://forum.fhem.de/index.php?msg=1350784 hat auch nicht geklappt:Das scheint ein curl-Aufruf von Linux zu sein, der unter Windows ausgeführt wird? Soweit ich weiß läuft unter Windows das Quoting anders. Also den Linux-Befehl kann man syntaktisch nicht 1:1 übernehmen. Also Single-Quotes kennt Windows-cmd erst einmal nicht. Könnte man evtl. so ersetzen:Code AuswählenC:\Users\Christoph>curl -X POST http://192.168.178.243/update -H 'Content-Type: application/json' --data '{"rom": {"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"},"spiffs": {"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
{"error":"could not parse HTTP body"}curl: (6) Could not resolve host: application
curl: (3) unmatched brace in URL position 1:
{url:
^
Code Auswählen
curl -X POST http://192.168.178.243/update -H "Content-Type: application/json" --data "{\"rom\": {\"url\": \"http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin\"},\"spiffs\": {\"url\": \"http://rgbww.dronezone.de/testing/spiff_rom.bin\"}}" #17
Unterstützende Dienste / Aw: Telegram instant messaging...
Letzter Beitrag von Raven - 19 Mai 2026, 10:00:04Ich hab mir schon einen Wolf gesucht, aber leider keinen Hinweis gefunden.
Ich möchte Nachrichten von zwei unterschiedlichen FHEM-Instanzen (PROD und UAT) an denselben Telegram-Bot senden. Da nur ein Telegram-Device "pollen" kann, arbeite ich mit dem entsprechenden Attribut von der 1.Seite:
Mein Versuch: Das Telegram-Device auf FHEM-PROD läuft unter "Polling" und das Device unter FHEM-UAT läuft unter "Static", aber ich bekomme die Fehlermeldung:
Interessanterweise, wenn ich zwei Telegram-Devices unter EINER gemeinsamen FHEM-Instanz laufen lasse, kann ich über beide Telegram-Devices Nachrichten versenden, ohne daß die o.g. Fehlermeldung bzgl. "Conflict..." erhalten. Ich hatte hier zunächst ein Telegram-Device definiert und konfiguriert, dann pollingTimeout auf 0 gesetzt, und dann das zweite Telegram-Device definiert und konfiguriert. Abschließend habe ich das erste Device wieder zum senden/empfangenden Device "gemacht" und das zweite Device nur auf "Static" gesetzt. Bin mir nicht sicher, ob dies nur ein "glücklicher" Zufall ist, dass es nun funktioniert oder aber an der Tatsache liegt, daß beide FEHM-Telegram-Devices auf einer FHEM-Instanz laufen.
Lange Rede: Wie schaffe ich, daß ich von zwei verschiedenen FHEM-Instanzen Nachrichten an den gleichen Telegram-Bot senden kann? Unter FHEM-Prod soll/kann das Telegram-Device Nachrichten senden/empfangen.
Muss ich in worst-case für die FHEM-UAT Instanz mir eine eigene Routine (99_myUtils.pm) schreiben und via Perl-Aufruf (curl...https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage...) die Nachricht versenden?
Danke vorab.
Ich möchte Nachrichten von zwei unterschiedlichen FHEM-Instanzen (PROD und UAT) an denselben Telegram-Bot senden. Da nur ein Telegram-Device "pollen" kann, arbeite ich mit dem entsprechenden Attribut von der 1.Seite:
Code Auswählen
Das Attribut pollingTimeout muss auf einen Wert > 0 gesetzt sein, sonst wird nichts empfangenMein Versuch: Das Telegram-Device auf FHEM-PROD läuft unter "Polling" und das Device unter FHEM-UAT läuft unter "Static", aber ich bekomme die Fehlermeldung:
Code Auswählen
Callback returned error :Conflict: terminated by other getUpdates request; make sure that only one bot instance is running:Interessanterweise, wenn ich zwei Telegram-Devices unter EINER gemeinsamen FHEM-Instanz laufen lasse, kann ich über beide Telegram-Devices Nachrichten versenden, ohne daß die o.g. Fehlermeldung bzgl. "Conflict..." erhalten. Ich hatte hier zunächst ein Telegram-Device definiert und konfiguriert, dann pollingTimeout auf 0 gesetzt, und dann das zweite Telegram-Device definiert und konfiguriert. Abschließend habe ich das erste Device wieder zum senden/empfangenden Device "gemacht" und das zweite Device nur auf "Static" gesetzt. Bin mir nicht sicher, ob dies nur ein "glücklicher" Zufall ist, dass es nun funktioniert oder aber an der Tatsache liegt, daß beide FEHM-Telegram-Devices auf einer FHEM-Instanz laufen.
Lange Rede: Wie schaffe ich, daß ich von zwei verschiedenen FHEM-Instanzen Nachrichten an den gleichen Telegram-Bot senden kann? Unter FHEM-Prod soll/kann das Telegram-Device Nachrichten senden/empfangen.
Muss ich in worst-case für die FHEM-UAT Instanz mir eine eigene Routine (99_myUtils.pm) schreiben und via Perl-Aufruf (curl...https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage...) die Nachricht versenden?
Danke vorab.
#18
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von pjakobs - 19 Mai 2026, 09:39:46Moin Christoph,
sorry, das das so lange gedauert hat, ich war unterwegs.
4.3.1-rc1 ist ja so alt nicht, ich galube, dass das OTA danach bis zur 5.0 nicht mehr angefasst wurde.
Dein json sieht okay aus,
die Fehlermeldung ist verwirrend:
die erste Fehlermeldung kommt sehr sicher hierher:
das ist ein leerer Request Body
die weiteren Teile kommen von curl - ich seh's noch nicht, aber irgendwas an Deiner curl Zeile stimmt nicht, Dein Rechner sendet eine leere Anfrage und curl versucht dann mit dem Rest der Zeile irgendwas anzufangen.
bei mir funktioniert die gleiche Zeile allerdings -
Die curl fehlermeldung "could not resolve host" lässt mich vermuten, dass irgendwie das "application/json" als host portion gelesen wurde, dann das "unmachted brace position.." - irgendwas stimmt mit dem Quoting in Deiner ursprünglichen Zeile nicht. Führst Das auf einer Linux Shell aus? Die Backslashes im Prompt lassen mich Windows befürchten, und da weiß ich nicht, ob ' und " genauso interpretiert werden wie unter Linux.
Wenn Du die Möglichkeit hast, führ doch die gleiche curl Zeile mal auf Linux aus, das sollte m.E. funktionieren
Grüße
pj
sorry, das das so lange gedauert hat, ich war unterwegs.
4.3.1-rc1 ist ja so alt nicht, ich galube, dass das OTA danach bis zur 5.0 nicht mehr angefasst wurde.
Dein json sieht okay aus,
Code Auswählen
{
"rom": {
"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"
},
"spiffs": {
"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"
}
}
die Fehlermeldung ist verwirrend:
Code Auswählen
{"error":"could not parse HTTP body"}
das sieht nach einer Fehlermeldung des Controllers aus - das ist ein "bad request"Code Auswählen
curl: (6) Could not resolve host: application
curl: (3) unmatched brace in URL position 1:
{url:
die erste Fehlermeldung kommt sehr sicher hierher:
Code Auswählen
String body = request.getBody();
if (body == NULL) {
sendApiCode(response, API_CODES::API_BAD_REQUEST, F("could not parse HTTP body"));
return;
}
das ist ein leerer Request Body
die weiteren Teile kommen von curl - ich seh's noch nicht, aber irgendwas an Deiner curl Zeile stimmt nicht, Dein Rechner sendet eine leere Anfrage und curl versucht dann mit dem Rest der Zeile irgendwas anzufangen.
bei mir funktioniert die gleiche Zeile allerdings -
Code Auswählen
$ curl -X POST http://192.168.29.101/update -H 'Content-Type: application/json' --data '{"rom": {"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"},"spiffs": {"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
{"success":true}
Die curl fehlermeldung "could not resolve host" lässt mich vermuten, dass irgendwie das "application/json" als host portion gelesen wurde, dann das "unmachted brace position.." - irgendwas stimmt mit dem Quoting in Deiner ursprünglichen Zeile nicht. Führst Das auf einer Linux Shell aus? Die Backslashes im Prompt lassen mich Windows befürchten, und da weiß ich nicht, ob ' und " genauso interpretiert werden wie unter Linux.
Wenn Du die Möglichkeit hast, führ doch die gleiche curl Zeile mal auf Linux aus, das sollte m.E. funktionieren
Grüße
pj
#19
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 19 Mai 2026, 09:29:39Moin,
sieht gut aus 300P.
Bei mir ebenfalls mit: v1_common_active.
sieht gut aus 300P.
Bei mir ebenfalls mit: v1_common_active.
#20
Sonstiges / Aw: Brauche Hilfe beim Bau ein...
Letzter Beitrag von betateilchen - 19 Mai 2026, 09:23:33FHEM-Statusanzeige mal anders..
Du darfst diesen Dateianhang nicht ansehen.
Die Statusanzeigen werden von FHEM als SIP Messages an die Telefontasten geschickt.
Fenster geschlossen = grün
Fenster gekippt = orange
Fenster offen = rot
Rollo offen = grün
Rollo teilweise geschlossen = orange
Rollo geschlossen = rot
Rollo in Bewegung = LED aus
Umgekehrt schickt das Telefon Tastencodes per INVITE an FHEM, um Aktionen auszulösen (z.B. Licht schalten), diese werden von FHEM per notify ausgewertet. Aktuell läuft das noch per INVITE-messages, das werde ich aber noch auf MESSAGE oder INFO umbauen.
Damit ist mein proof-of-concept zu der Idee erstmal fertig.
Im Endausbau soll das alles noch ein bisschen komfortabler und universeller werden.
Beispielsweise soll die Statusanzeige dann quasi als Besetzt-Lampenfeld arbeiten, das heißt, das Telefon schickt per SUBSCRIBE Informationen an FHEM, welche Tasten welche ID (aka FHEM-device) "überwachen" möchten. Und FHEM reagiert dann bei Statusänderungen der gewünschten ID und schickt eine entsprechende NOTIFY-message per SIP an das Telefon.
Du darfst diesen Dateianhang nicht ansehen.
Die Statusanzeigen werden von FHEM als SIP Messages an die Telefontasten geschickt.
Fenster geschlossen = grün
Fenster gekippt = orange
Fenster offen = rot
Rollo offen = grün
Rollo teilweise geschlossen = orange
Rollo geschlossen = rot
Rollo in Bewegung = LED aus
Umgekehrt schickt das Telefon Tastencodes per INVITE an FHEM, um Aktionen auszulösen (z.B. Licht schalten), diese werden von FHEM per notify ausgewertet. Aktuell läuft das noch per INVITE-messages, das werde ich aber noch auf MESSAGE oder INFO umbauen.
Damit ist mein proof-of-concept zu der Idee erstmal fertig.
Im Endausbau soll das alles noch ein bisschen komfortabler und universeller werden.
Beispielsweise soll die Statusanzeige dann quasi als Besetzt-Lampenfeld arbeiten, das heißt, das Telefon schickt per SUBSCRIBE Informationen an FHEM, welche Tasten welche ID (aka FHEM-device) "überwachen" möchten. Und FHEM reagiert dann bei Statusänderungen der gewünschten ID und schickt eine entsprechende NOTIFY-message per SIP an das Telefon.