Bis heute Mittag lief meine HUEBridge einwandfrei. Sie wurde beim fhem-Start sofort erkannt und Alles lief gut.
2020.08.13 13:13:53 3: HUEBridge_Detect
2020.08.13 13:13:53 3: HUEBridge_Detect: 192.168.250.25
Seitdem habe ich ein Reading, dass es ein Softwareupdate gäbe und nichts läuft mehr.
READINGS:
2020-08-13 19:09:26 state initialized
2020-08-13 13:18:50 swupdate BSB001 - 1.36.1RC2
2020.08.13 14:44:41 3: HUEBridge_Detect
2020.08.13 14:44:42 3: HUEBridge_Detect: error detecting bridge.
2020.08.13 14:44:42 3: HUEBridge_Detect
2020.08.13 14:44:42 3: HUEBridge_Detect: error detecting bridge.
2020.08.13 14:44:42 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/30_HUEBridge.pm line 441.
2020.08.13 14:44:42 2: HUEBridge_OpenDev: error reading description: http:///description.xml: malformed or unsupported URL
2020.08.13 14:44:42 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/30_HUEBridge.pm line 1727.
2020.08.13 14:44:42 1: HUEBridge_HTTP_Request http:///api/c1718dbde308c436ce3c40456f987a63/config: malformed or unsupported URL
2020.08.13 14:44:42 3: HUEBridge_Call: failed, retrying
2020.08.13 14:44:42 3: HUEBridge_Detect
2020.08.13 14:44:43 3: HUEBridge_Detect: error detecting bridge.
2020.08.13 14:44:43 1: HUEBridge_HTTP_Request http:///api/c1718dbde308c436ce3c40456f987a63/config: malformed or unsupported URL
2020.08.13 14:44:43 3: HUEBridge_Call: failed, retrying
2020.08.13 14:44:43 3: HUEBridge_Detect
2020.08.13 14:44:43 3: HUEBridge_Detect: error detecting bridge.
2020.08.13 14:44:43 3: HUEBridge_Call: failed
2020.08.13 14:44:43 2: HUEBridge_OpenDev: got empty config
Bin ich alleine mit dem Problem oder hat es sonst noch jemand?
Gibt es Lösungen?
PS: Ich habe heute ein update gemacht, aber das Modul HUEBridge war nicht dabei.
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2020.08.13 14:44:21 1:
2020.08.13 14:44:21 1: fhem
2020.08.13 14:44:21 1: RMDIR: ./restoreDir/update/2020-06-23
2020.08.13 14:44:21 1: UPD ./CHANGED
2020.08.13 14:44:21 1: UPD FHEM/10_CUL_HM.pm
2020.08.13 14:44:21 1: UPD FHEM/49_SSCam.pm
2020.08.13 14:44:21 1: UPD FHEM/60_Watches.pm
2020.08.13 14:44:21 1: UPD FHEM/73_AutoShuttersControl.pm
2020.08.13 14:44:21 1: UPD FHEM/98_DOIF.pm
2020.08.13 14:44:21 1: UPD FHEM/lib/AttrTemplate/mqtt2.template
2020.08.13 14:44:22 1: UPD lib/FHEM/Automation/ShuttersControl.pm
2020.08.13 14:44:22 1: UPD lib/FHEM/Automation/ShuttersControl/Helper.pm
2020.08.13 14:44:22 1: UPD lib/FHEM/Automation/ShuttersControl/Shading.pm
2020.08.13 14:44:22 1: UPD lib/FHEM/Automation/ShuttersControl/Shutters.pm
2020.08.13 14:44:22 1:
2020.08.13 14:44:22 1: New entries in the CHANGED file:
2020.08.13 14:44:22 1: - feature: 49_SSCam: new attribute ptzNoCapPrePat
2020.08.13 14:44:22 1: - feature: 60_Watches: control buttons,new attr hideButtons, controlButtonSize
2020.08.13 14:44:22 1: some more changes according PBP
2020.08.13 14:44:22 1: - bugfix: 73_AutoShuttersControl: change from %k to %H for better compability
2020.08.13 14:44:22 1: with Strawberry Perl on Windows
2020.08.13 14:44:22 1: fix Github #82
2020.08.13 14:44:22 1: fix Github #79
2020.08.13 14:44:22 1: fix Github #77
2020.08.13 14:44:22 1:
2020.08.13 14:44:22 1: Downloading https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
2020.08.13 14:44:22 1:
2020.08.13 14:44:22 1: fhemtabletui
2020.08.13 14:44:22 1: nothing to do...
2020.08.13 14:44:22 1:
2020.08.13 14:44:22 1: Downloading https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt
2020.08.13 14:44:22 1:
2020.08.13 14:44:22 1: fuip
2020.08.13 14:44:22 1: nothing to do...
2020.08.13 14:44:22 1: Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2020.08.13 14:44:26 1:
2020.08.13 14:44:26 1: update finished, "shutdown restart" is needed to activate the changes.
Anscheinend findet er dein Bridge nicht (mehr).
Was sagt https://discovery.meethue.com in einem Browser, bzw ein "curl https://discovery.meethue.com" auf dem Fhem Rechner?
Es scheint so zu sein, dass er die Bridge nicht mehr findet.
Der Befehl:
root@uhs:~# curl https://discovery.meethue.com
[]
root@uhs:~# curl http://discovery.meethue.com
<a href="https://discovery.meethue.com/">Moved Permanently</a>.
Wenn ich im Browser die IP-Adresse eingebe, antwortet die Bridge und über die HUE-App kann ich sie normal bedienen. Neustart der Bridge habe ich auch schon gemacht.
Als nächstes habe ich in fhem eine neue Bridge definiert mit Angabe der IP.
Resultat:
2020.08.14 10:45:24 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e3da410)
2020.08.14 10:45:24 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e1fe818)
2020.08.14 10:45:25 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 3: HUEBridge_Call: failed
2020.08.14 10:45:25 2: HUEBridge_OpenDev: got empty config
Was bedeutet "invalid json detected"? Liegt das an der Bridge oder am Modul?
Zitatroot@uhs:~# curl https://discovery.meethue.com
[]
root@uhs:~# curl http://discovery.meethue.com
<a href="https://discovery.meethue.com/">Moved Permanently</a>.
[]
Das ist komisch. Da antwortet er mit einem leeren []. Das hängt mMn an deiner Bridge oder an deiner Netzwerkkonfiguration.
Was sagt https://discovery.meethue.com in einem Browser. (Bitte nicht die IP Adresse der Bridge nutzen, sondern genau diese URL)
Man muss sich nicht wundern, wenn es danach nicht richtig funktioniert.
Beim Aufruf über den Browser ist es auch leer.
An den Netzwerkeinstellungen habe ich ewig nichts geändert. Mein ganzes Home-Netzwerk ist hinter einer Sophos UTM Firewall und das seit Jahren.
Ist dein Bridge immer noch bei meethue registriert?
Ich kann mich nicht erinnern, ob die Bridge in den vielen Jahren jemals bei meethue registriert war. Wo könnte ich das nachschauen?
Wie geschrieben, die originale Hue-App, wie auch Hue essentials funktionieren.
Kannst Du ein "list" von deinem HUEBridge Device liefern? (ggf anonymisiert)
Internals:
FUUID 5c42f42f-f33f-d4cb-c4ff-230a48bb2d0784ba
FVERSION 30_HUEBridge.pm:0.213660/2020-03-06
INTERVAL 60
NAME HB
NOTIFYDEV global
NR 73
NTFY_ORDER 50-HB
NUPNP 1
STATE initialized
TYPE HUEBridge
host
READINGS:
2019-11-14 19:28:41 lastError resource, /scenes/Abendlicht, not available
2020-08-16 17:51:53 state initialized
2020-08-13 13:18:50 swupdate BSB001 - 1.36.1RC2
helper:
count 0
last_config_timestamp 1597653218
Attributes:
icon hue_filled_bridge_v1
key c1718dbde308c436ce3c40456f987a63
pollDevices 1
queryAfterSet 1
room HUEDevice,Licht
Also, ja, es bleibt im Status "initialized".
Es reicht wahrscheinlich ein neues Pairing mit Fhem: attr key löschen, und dann Knopf an der Bridge drucken (oder ins Pairing Mode bringen über die Weboberfläsche, wenn Deconz o.ä)
Eventuell auch mal "frech und frei" ein:
set HB active
Gruß, Joachim
Es wäre so schön, wenn es so einfach wäre.
Wie schon in Post Nr.2 geschrieben habe ich es auch schon mit einer Neuanlage der Bridge in fhem versucht.
Jetzt habe ich Eure Tips widerholt angewendet.
Key gelöscht und neu gepairt. Es bleibt beim 'initialized', aber neuem Key.
Danach nochmal 'set HB active'.
Internals:
FUUID 5c42f42f-f33f-d4cb-c4ff-230a48bb2d0784ba
FVERSION 30_HUEBridge.pm:0.213660/2020-03-06
INTERVAL 60
NAME HB
NOTIFYDEV global
NR 73
NTFY_ORDER 50-HB
NUPNP 1
STATE active
TYPE HUEBridge
host
READINGS:
2019-11-14 19:28:41 lastError resource, /scenes/Abendlicht, not available
2020-08-18 17:44:09 state active
2020-08-13 13:18:50 swupdate BSB001 - 1.36.1RC2
helper:
count 0
last_config_timestamp 0
Attributes:
icon hue_filled_bridge_v1
key 8e85b966e384daf1962a9af7dc795af6
pollDevices 1
queryAfterSet 1
room HUEDevice,Licht
und im log:
2020.08.18 17:44:09 3: HUEBridge_Detect
2020.08.18 17:44:09 3: HUEBridge_Detect: error detecting bridge.
2020.08.18 17:44:09 2: HUEBridge_OpenDev: error reading description: http:///description.xml: malformed or unsupported URL
2020.08.18 17:44:09 1: HUEBridge_HTTP_Request http:///api/8e85b966e384daf1962a9af7dc795af6/config: malformed or unsupported URL
2020.08.18 17:44:09 3: HUEBridge_Call: failed, retrying
2020.08.18 17:44:09 3: HUEBridge_Detect
2020.08.18 17:44:09 3: HUEBridge_Detect: error detecting bridge.
2020.08.18 17:44:09 1: HUEBridge_HTTP_Request http:///api/8e85b966e384daf1962a9af7dc795af6/config: malformed or unsupported URL
2020.08.18 17:44:09 3: HUEBridge_Call: failed, retrying
2020.08.18 17:44:09 3: HUEBridge_Detect
2020.08.18 17:44:09 3: HUEBridge_Detect: error detecting bridge.
2020.08.18 17:44:09 3: HUEBridge_Call: failed
2020.08.18 17:44:09 2: HUEBridge_OpenDev: got empty config
Mir sind die Ideen schon lange ausgegangen. Ich hoffe immer noch auf eine zündende.
Was mich bei deinem list wundert:
der DEF-Teil ist gar nicht zu sehen!?
Auf welchem System läuft denn fhem!?
Schon mal die Attribute noshutdown bzw. httpUtils gesetzt!?
Die Attribute die du gesetzt hast (manuell/selber!?) sind bei mir nicht gesetzt...
Wobei ich jetzt keine echte HueBridge (echt du hast eine V1!?) habe, sondern eben deCONZ mit dem Raspbee-Modul auf einem weiteren PI...
Gruß, Joachim
Hallo Joachim,
das ganze läuft seit mindestens 2 Jahren so auf einem Ubuntu 18.04 Server.
Es hat sich alles so angelgt und hat bis zum 13.8. funktioniert.
Leider habe ich kein List von der funktionierenden Bridge. Da war natürlich die def gefüllt, aber wie das log zeigt 'HUEBridge_OpenDev: got empty config'.
Es handelt sich wirklich um eine alte Version 1 Bridge, die auch von Philips nicht mehr supportet wird. Aber bis vor einer Woche ging sie und außerhalb von fhem geht sie auch. Nur die cloud-Dienste sind beschränkt, aber die wollte ich sowieso nie nutzen.
Philips-Hue-Bridge Gen. 1 geht wie angekündigt in Software-Rente
Was Signify (ehemals Philips Lighting) Ende April 2019 angekündigt hatte, wird jetzt in die Tat umgesetzt: Besitzer der Philips-Hue-Bridge der ersten Generation müssen sich darauf einstellen, dass die Hardware ab dem 30. April 2020 keine Software-Updates mehr erhält. Das Gerät, was Anschluss an den Router findet und als Schaltzentrale für das Smart-Light-System dient, war 2012 auf den Markt gekommen, seit 2015 ist die zweite Generation der Hue Bridge verfügbar. Die Unterscheidung fällt dabei leicht: Geräte der ersten Generation 1. sind rund, die Nachfolgegeräte sind quadratisch.
Nach dem Stichtag ist es zwar auch mit der alten Hue Bridge weiterhin möglich, die Lampen des Hue-Systems mit der entsprechenden App zu steuern, wenn sich Bridge und Smartphone im gleichen WLAN-Netzwerk befinden. Mit dem Ende des Software-Supports kappt Philips aber die Anbindung an seinen Cloud-Dienst. Damit verlieren Nutzer der Philips-Hue-Bridge der ersten Generation die Möglichkeit, das System aus der Ferne zu steuern. Damit verbunden ist dann auch noch der Wegfall der Möglichkeit, das System über digitale Assistenten wie Google Home oder Alexa zu steuern - auch diese Funktionen setzen auf die Anbindung mit der Hue Cloud.
wenn du keine ip angibst versucht das modul die bridge über den hue cloud dienst zu finden. wenn das für eine alte bridge nicht mehr geht wird sie halt nicht gefunden. also ip selber im define angeben und fertig.
Hallo justme1968,
diesen Vorschlag habe ich schon in Antwort #2 umgesetzt. Siehe Ergebnis und Frage daraus.
Zitat von: wk am 14 August 2020, 10:50:22
Als nächstes habe ich in fhem eine neue Bridge definiert mit Angabe der IP.
Resultat:
2020.08.14 10:45:24 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e3da410)
2020.08.14 10:45:24 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e1fe818)
2020.08.14 10:45:25 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 3: HUEBridge_Call: failed
2020.08.14 10:45:25 2: HUEBridge_OpenDev: got empty config
Was bedeutet "invalid json detected"? Liegt das an der Bridge oder am Modul?
Edit:Ich nehme Alles zurück und behaupte das Gegenteil ;)
Denn bei meinem Versuch von Antwort #2 hatte ich einen Zahlendreher in der Ip-Adresse.
Dieser ist mir die ganze Zeit nicht aufgefallen, sonst wäre das Problem schon lange gelöst. (Der Wald und die Bäume)
Anbei der Anfang des funktionierenden Lists:
Internals:
DEF 192.168.250.25
FUUID 5f3cdbf5-f33f-d4cb-26de-0a555bd42b93de0d
FVERSION 30_HUEBridge.pm:0.213660/2020-03-06
INTERVAL 60
NAME HB1
NOTIFYDEV global
NR 542
NTFY_ORDER 50-HB1
STATE connected
TYPE HUEBridge
apiversion 1.16.0
host 192.168.250.25
mac 00:17:88:1c:90:40
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2012
modelid BSB001
name Philips hue
swversion 01043155
updatestate 0
zigbeechannel 11
READINGS:
2020-08-19 10:04:10 lastError link button not pressed
2020-08-19 10:10:16 state connected
helper:
apiversion 69632
count 1
last_config_timestamp 1597824616
offsetUTC 7200
updatestate 0
Warum fhem plötzlich die Definition vergessen hatte ist mir zwar immer noch nicht klar, aber Hauptsache ist, es funktioniert wieder.
Vielen Dank für Eure Anregungen.
Walter
Hmm, also ich habe seit heute dasselbe Problem. Am Wochende hatte ich mein deCONZ umgezogen. Da lief noch alles. Heute nach der Neuinstalltion klappt es nicht mehr :-[
Internals:
CFGFN
DEF 192.168.40.22
FUUID 63f3f77b-f33f-13a0-8b6f-0e3169af2824903e
FVERSION 30_HUEBridge.pm:0.264380/2022-09-22
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 1480
NTFY_ORDER 50-deCONZ
STATE active
TYPE HUEBridge
eventCount 2
host 192.168.40.22
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
Helper:
DBLOG:
state:
myDbLog:
TIME 1676933013.5164
VALUE active
READINGS:
2023-02-20 23:43:33 state active
helper:
count 2
last_config_timestamp 0
bm:
HUEBridge_Attr:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 20.02. 23:43:24
max 7.15255737304688e-06
tot 7.15255737304688e-06
mAr:
set
deCONZ
room
Arbeitszimmer
HUEBridge_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 20.02. 23:43:15
max 8.01697707176208
tot 8.01697707176208
mAr:
HASH(0x561801721600)
deCONZ HUEBridge 192.168.40.22
HUEBridge_Get:
cnt 5
dmx -1000
dtot 0
dtotcnt 0
mTS 20.02. 23:43:31
max 1.31130218505859e-05
tot 6.29425048828125e-05
mAr:
HASH(0x561801721600)
deCONZ
?
HUEBridge_Notify:
cnt 9
dmx -1000
dtot 0
dtotcnt 0
mTS 20.02. 23:43:44
max 2.59876251220703e-05
tot 8.08238983154297e-05
mAr:
HASH(0x561801721600)
HASH(0x5617f831f6a0)
HUEBridge_Set:
cnt 16
dmx -1000
dtot 0
dtotcnt 0
mTS 20.02. 23:44:19
max 24.0671699047089
tot 32.0873172283173
mAr:
HASH(0x561801721600)
deCONZ
autocreate
ignored:
hmccu:
Attributes:
key bd20e7713c59aa4ed153baea3f3e305b
room Arbeitszimmer
Den deCONZ habe ich vor dem "define" natürlich brav auf "unlocked" gesetzt. Per tcpdump ist zu sehen, dass Pakete vom FHEM ankommen. Im FHEM log finde ich aber nur Timeouts:
2023.02.20 23:43:37 1: HUEBridge_HTTP_Request http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config: Select timeout/error:
2023.02.20 23:43:37 3: HUEBridge_Call: failed, retrying
2023.02.20 23:43:41 1: HUEBridge_HTTP_Request http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config: Select timeout/error:
2023.02.20 23:43:41 3: HUEBridge_Call: failed, retrying
2023.02.20 23:43:41 3: HUEBridge_Call: failed
2023.02.20 23:43:41 2: HUEBridge_OpenDev: got empty config
Problem ist, die Confihg ist nicht leer, ich bekomme sie mit curl problemlos:
[fhem@fhem log]$ curl -s http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config | jq .
{
"apiversion": "1.16.0",
"bridgeid": "00212EFFFF02A3FE",
"datastoreversion": "93",
"devicename": "ConBee",
"factorynew": false,
"mac": "02:42:ac:11:00:02",
"modelid": "deCONZ",
"name": "Phoscon-GW",
"replacesbridgeid": null,
"starterkitid": "",
"swversion": "2.20.1"
}
Das einzige, was ich wissentlich seit dem Wochenende geändert habe, ist ein Firmware Upgrade des Conbee auf 26400500. deCONZ selber ist unverändert auf "2.20.01 / 19.9.2022". Wenn FHEM das JSON plötzlich nicht mehr geparst bekommen sollte, würde ich andere Fehler erwarten. Zudem funtionieren anderen REST Zugriffe, z.B. auf Shellys, etc. problemlos. Ich stehe aktuell auf dem Schlauch :-[
VG, Marc
Also man sieht im tcpdump/wireshark eigentlich ganz gut, dass die Kommunikation funktioniert, erst wir die Description angefragt und ausgeliefert, das funktioniert noch. Dann wird die config angefragt und ebenfalls ausgeliefert. Allerdings wird dies von "HUEBridge_HTTP_Request" nicht erkannt/akzeptiert. Es kommt zum Timeout, danach wird config ein zweites Mal angefragt, erneut ausgeliefert und erneut nicht erkannt. Zweiter Timeout, Ende der Kommunikation. :-[
Moin!
Ich habe in 30_HUEBridge.pm die Funktion HUEBridge_HTTP_Request jetzt recht stumpf gemäß HttpUtils.pm ersetzt:
sub
HUEBridge_HTTP_Request($$$@)
{
my ($quiet, $url, $method, $timeout, $data, $noshutdown) = @_;
return CustomGetFileFromURL($quiet, $url, $timeout, $data, $noshutdown, 3);
}
Damit ist der define auf Anhieb durchgelaufen
023.02.22 23:39:55 3: http://phoscon/api/afb3c0209e5beba894ca7117b12d3d90/config: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/config: HTTP response code 200
2023.02.22 23:39:55 3: deCONZ: websocket opened to phoscon:443
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice1: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/1: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice2: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/2: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice3: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/3: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice4: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/4: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/groups: HTTP response code 200
2023.02.22 23:39:55 3: HUEGroup0: I/O device is deCONZ
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05/groups/0: HTTP response code 200
2023.02.22 23:39:56 3: HUEGroup1: I/O device is deCONZ
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05/groups/1: HTTP response code 200
2023.02.22 23:39:56 2: deCONZ: autocreate: created 4/2/0 devices (ignored 0/0/0)
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05: HTTP response code 200
2023.02.22 23:39:56 3: deCONZ: websocket: Switching Protocols ok
Hast/hattest du es mal mit gesetztem Attribut httpUtils (bzw. und noshutdown) probiert?
Gruß, Joachim
wie komst du eigentlich darauf das irgend ein x-beliebiger uralt thread mit einem titel der nicht zu deinem problem passt bei dem es um eine hardware geht die du nicht hast und der seit Ewigkeiten gelöst ist zu deinem problem passen könnte?
welche version habe deine fhem hue module?
Hi!
Die soweit ich sehe aktuelle Version 26438 vom 22.09.22. Ja, den Thread zu nutzen war suboptimal. Das nächste Mal mache ich einen neuen auf!
VG, Marc
Zitat von: MadMax-FHEM am 23 Februar 2023, 07:41:11
Hast/hattest du es mal mit gesetztem Attribut httpUtils (bzw. und noshutdown) probiert?
Mit "httpUtils = 1" tut es, vielen Dank :) War früher in meinem Setup nicht notwendig, jetzt offensichtich schon.
VG, Marc