- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
FHEM Code changes / Revision 31246: controls_fhem....
Letzter Beitrag von System - 19 Mai 2026, 08:11:11Revision 31246: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31246: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31246: controls_fhem.txt: fhemupdate checkin
#2
MQTT / Aw: Blink-Kameras MQTT-Bridge
Letzter Beitrag von JoWiemann - 19 Mai 2026, 07:30:26Zitat von: TomLee am 18 Mai 2026, 21:24:27Zitat...Dann lieber eine defekten RPi ersetzen. ...
Kurz OT, sry.
Mit SD oder SSD?
Aus meiner Sicht ist das egal. Moderne SD unterscheiden sich eigentlich nicht mehr von einer SSD. Am Ende ist es eher Qualität und ihr Preis. Ich habe einen RPi mit einer SD seid 4 Jahren ohne Probleme laufen. Bei einem zweiten war die SSD nach zwei Jahren defekt. War halt ein Schnäppchenkauf.
#3
Sprachsteuerung / Aw: HomebridgeMapping korrektu...
Letzter Beitrag von Steffen@Home - 19 Mai 2026, 07:18:12Ich meinte natürlich im CurrentDoorState --> stop <> stopped
#4
Multimedia / Aw: Bose und soundcork und FHE...
Letzter Beitrag von tostmann - 19 Mai 2026, 00:26:00Hallo Jörg,
Revert ist symmetrisch zur Migration und steht beides im README beschrieben: https://github.com/tostmann/BoseFix32#what-it-does-on-the-speaker
Kurz: BoseFix32 öffnet den Telnet-Diag-Shell des Speakers auf Port 17000, schreibt mit envswitch boseurls set die URL-Liste in der NVRAM-Config um und triggert einen Reboot. Bei der Migration zeigen die URLs auf den ESP (http://<bosefix-ip>:8000), beim Revert zurück auf die Original-Bose-Hostnamen. Die Original-URLs hält BoseFix32 sich vor dem ersten Migrate weg.
Kein TLS-Eingriff, kein USB-Recovery, kein SSH — die boseurls sind reine HTTP-URLs ohne Cert-Pinning, deshalb ist der Vorgang in beide Richtungen risikofrei: solange Port 17000 erreichbar ist, kommst du immer wieder auf den Bose-Original-Stand zurück.
Implementierung: speaker_telnet.cpp::revertSpeaker() im Repo.
Revert ist symmetrisch zur Migration und steht beides im README beschrieben: https://github.com/tostmann/BoseFix32#what-it-does-on-the-speaker
Kurz: BoseFix32 öffnet den Telnet-Diag-Shell des Speakers auf Port 17000, schreibt mit envswitch boseurls set die URL-Liste in der NVRAM-Config um und triggert einen Reboot. Bei der Migration zeigen die URLs auf den ESP (http://<bosefix-ip>:8000), beim Revert zurück auf die Original-Bose-Hostnamen. Die Original-URLs hält BoseFix32 sich vor dem ersten Migrate weg.
Kein TLS-Eingriff, kein USB-Recovery, kein SSH — die boseurls sind reine HTTP-URLs ohne Cert-Pinning, deshalb ist der Vorgang in beide Richtungen risikofrei: solange Port 17000 erreichbar ist, kommst du immer wieder auf den Bose-Original-Stand zurück.
Implementierung: speaker_telnet.cpp::revertSpeaker() im Repo.
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 18 Mai 2026, 22:35:04So sieht meins aus 
PS:
Heute
PV Abweichung fortlaufend: -11,7 %, gestern: 22,9 %
CON Abweichung fortlaufend: 2,3 %, gestern: 12 %
PS:
Heute
PV Abweichung fortlaufend: -11,7 %, gestern: 22,9 %
CON Abweichung fortlaufend: 2,3 %, gestern: 12 %
#6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 18 Mai 2026, 22:24:33Schauen wir mal was die verschiedenen Einstellungen bringen. Mit dem Profil v1_common_active bekomme ich aktuell das angehängte Bild. Mal schauen wie es sich morgen entwickelt.
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 18 Mai 2026, 21:58:38PV habe ich ja länger schon mit > 30 kWh/Tag in den letzten 2 Monaten. (Grafik)
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Meine "Freunde im Internet" haben mir heute Abend noch eine Einstellung vorgeschlagen und optimiert die ich niemals nicht bislang so probiert / eingestellt hätte....
aiControl:
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Meine "Freunde im Internet" haben mir heute Abend noch eine Einstellung vorgeschlagen und optimiert die ich niemals nicht bislang so probiert / eingestellt hätte....
aiControl:
Code Auswählen
aiConActFunc=SIGMOID_SYMMETRIC
aiConActivate=1
aiConAlpha=0.7
aiConBitFailLimit=0.30
aiConHiddenLayers=30-15
aiConLearnRate=0.001
aiConMomentum=0.4
aiConProfile=v1_heatpump_pv
aiConShuffleMode=1
aiConShufflePeriod=15
aiConSteepness=0.5
aiConTrainAlgo=RPROP
aiConTrainStart=7:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30
Code Auswählen
letzte KI-Ergebnis Generierungsdauer: 82.71 ms
Alpha: 0.7
Verbrauchernummer Wärmepumpe: 08
Bewertungsüberblick
Trainingsbewertung: ok (ok)
Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
Drift Bewertung: -
Empfehlung für Retrain: keine (Grund: -)
Modellparameter
Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
Trainingsdaten: 9555 Datensätze (Training=7644, Validation=1911)
Architektur: Inputs=94, Hidden Layers=30-15, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.4, BitFail-Limit=0.30
Aktivierungen: Hidden=SIGMOID_SYMMETRIC, Steepness=0.5, Output=LINEAR
Trainingsalgorithmus: RPROP, Registry Version=v1_heatpump_pv
Zufallsgenerator: Mode=1, Period=15
Modellalter: - h
Trainingsmetriken
bestes Modell bei Epoche: 49 (max. 15000)
Training MSE: 0.006517
Validation MSE: 0.005268
Validation MSE Average: 0.008801
Validation MSE Standard Deviation: 0.000033
Validation Bit_Fail: 5
Model Bias: 375 Wh
Model Slope: 0.76
Trainingsbewertung: ok
Fehlermaße der Prognosen
MAE: 362.30 Wh
MedAE: 261.50 Wh
RMSE: 422.21 Wh
RMSE relative: 30 %
RMSE Rating: good
MAPE: 26.99 %
MdAPE: 19.04 %
R²: 0.61
Rauschen
Rauschen Bewertung: borderline
Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)
#8
MQTT / Aw: Blink-Kameras MQTT-Bridge
Letzter Beitrag von TomLee - 18 Mai 2026, 21:24:27Zitat...Dann lieber eine defekten RPi ersetzen. ...
Kurz OT, sry.
Mit SD oder SSD?
#9
MQTT / Aw: Blink-Kameras MQTT-Bridge
Letzter Beitrag von JoWiemann - 18 Mai 2026, 21:12:37Hallo TomLee,
ich habe nur einen MQTT2Server. Überdiesen erhalte ich Daten von drei Instanzen im ioBroker, drei ESP32 Devices, ZigBee2MQTT, meiner Eimsig Alarmanlage und jetzt Blink-Bridge. Device Vervielfältigung habe ich noch nie als Problem gehabt.
Ich habe den ioBroker in einem Docker auf meinem NAS laufen. Selbst mit macvlan habe ich es hier nicht geschafft über MQTT irgendetwas zu schalten. Zur Zeit überlege ich den ioBroker auf einen eigenen RPi zu verlagern.
Für mich ist ein RPi ein Hardware Container. Das Synology NAS DS218 kommt bei Docker, trotz Aufrüstung, immer wieder an seine Grenzen und einen entsprechend potenten Server für gute Containerisierung ist mir zu teuer. Dann lieber eine defekten RPi ersetzen. Im Stromverbrauch tut sich das nichts.
Grüße Jörg
ich habe nur einen MQTT2Server. Überdiesen erhalte ich Daten von drei Instanzen im ioBroker, drei ESP32 Devices, ZigBee2MQTT, meiner Eimsig Alarmanlage und jetzt Blink-Bridge. Device Vervielfältigung habe ich noch nie als Problem gehabt.
Ich habe den ioBroker in einem Docker auf meinem NAS laufen. Selbst mit macvlan habe ich es hier nicht geschafft über MQTT irgendetwas zu schalten. Zur Zeit überlege ich den ioBroker auf einen eigenen RPi zu verlagern.
Für mich ist ein RPi ein Hardware Container. Das Synology NAS DS218 kommt bei Docker, trotz Aufrüstung, immer wieder an seine Grenzen und einen entsprechend potenten Server für gute Containerisierung ist mir zu teuer. Dann lieber eine defekten RPi ersetzen. Im Stromverbrauch tut sich das nichts.
Grüße Jörg
#10
MQTT / Aw: Blink-Kameras MQTT-Bridge
Letzter Beitrag von JWRu - 18 Mai 2026, 21:01:06@JoWiemann
Ok - habe ich jetzt verstanden: Wir haben unterschiedliche Setups.
Ich habe das hier: https://github.com/weirdtangent/blink2mqtt in einem Docker-Container auf meinem Synology-NAS installiert.
Das legt zwar MQTT-Topics in FHEM an, aber die Verbindung zu Blink klappt nicht richtig und der Container macht immer wieder Restarts.
Die MQTT-sets funktionieren jedenfalls nicht.
Dann werde ich mal die andere Lösung ausprobieren, wenn ich dazu komme. Das blink2mqtt-Problem mit den ständig wechselnden CIDs, das einen zweiten MQTT2SERVER erfordert, gibt's da anscheinend ja nicht.
Ok - habe ich jetzt verstanden: Wir haben unterschiedliche Setups.
Ich habe das hier: https://github.com/weirdtangent/blink2mqtt in einem Docker-Container auf meinem Synology-NAS installiert.
Das legt zwar MQTT-Topics in FHEM an, aber die Verbindung zu Blink klappt nicht richtig und der Container macht immer wieder Restarts.
Die MQTT-sets funktionieren jedenfalls nicht.
Dann werde ich mal die andere Lösung ausprobieren, wenn ich dazu komme. Das blink2mqtt-Problem mit den ständig wechselnden CIDs, das einen zweiten MQTT2SERVER erfordert, gibt's da anscheinend ja nicht.