- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
EnOcean / Aw: EnOcean TCM310(USB300) Gat...
Letzter Beitrag von leupin - 24 Mai 2025, 01:08:57Vielen Dank - das habe ich nach meinen Erfahrungen so vermutet und Du bestätigst das nun so - dann bleibt wohl nur der Weg, dass ich die EnOcean-Sensoren weiterhin über FHEM auslese und dann über die FHEM-Homebridge an Apple Home übertrage...
#2
FHEM Code changes / Revision 29993: 76_SolarForeca...
Letzter Beitrag von System - 23 Mai 2025, 23:41:03Revision 29993: 76_SolarForecast: contrib Version 1.52.5
76_SolarForecast: contrib Version 1.52.5
Source: Revision 29993: 76_SolarForecast: contrib Version 1.52.5
76_SolarForecast: contrib Version 1.52.5
Source: Revision 29993: 76_SolarForecast: contrib Version 1.52.5
#3
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 23 Mai 2025, 23:32:39Für Peter habe ich noch die Nullen zueinander ausgerichtet. 
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Max_Meyer - 23 Mai 2025, 22:36:21Zitat von: DS_Starter am 23 Mai 2025, 22:21:04Der Vorteil des Setzens via attrKeyVal hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrung gecheckt wird und ggf. ein Fehler zurückgegeben wird den der User im Script auswerten kann und damit die Fehlermöglichkeiten minimiert werden.
Um deine Idee aufzugreifen, wäre ein weiterer Schlüssel "lcBool=<Device>:<Reading>" denkbar, welches ein logisches true / false liefern kann, um die Ladung unter Modulkontrolle (1) bzw. ohne Modulkontrolle, d.h. mit voller Leistung (0) zu realisieren.
Die Verwendung von lcSlot und lcBool kann ich durch Prüfung gegeneinander ausschließen, d.h. der User kann nur eine der Varianten gleichzeitig setzen.
Das "lc" steht in diesen Schlüssel für "load control".
Guten Abend Heiko,
Zuerst einmal: Danke für deine schnelle und ausführliche Antwort!
Einen zusätzlichen Schlüssel braucht es m.M.n. dann nicht - die Idee mit 'set ... attrKeyVal' ist so OK und kann ja auch flexibel in jede Logik eingepasst werden
Gruß Gerd
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 23 Mai 2025, 22:21:04Hallo Gerd,
Momentan, wenn lcSlot nicht gesetzt ist, entspricht es im Prinzip deinem "false" sofern man darunter versteht dass das Lademanagement aktiv ist und eine Empfehlung per Reading steuert mit welcher Leistung geladen werden sollte. Das ist der default.
Nun kann man mit lcSlot die Steuerung nur auf einen täglichen Slot eingrenzen, in dem die Batterie der Steuerung vom Modul unterliegt, aber sonst mit der vollen möglichen Leistung geladen wird.
Wir haben momentan keinen Modus der das Laden quasi logisch "unterbindet", sondern mit 0 nur einschränkt (Laden bei Überschreitung eines Einspeiselimits) bzw. 1 Laden mit voller Leistung was möglich ist. Die Zeit außerhalb des Slots würde einem "true" entsprechen. Das bedeutet "true" -> immer Laden mit max. möglicher Leistung, "false" -> Laden unter Modulsteuerung.
Um ein von dir skizziertes Szenario mit z.B. 3 Batterien umzusetzen, könnte man so vorgehen:
1. die Bat 1 soll mit voller Leistung geladen werden, die anderen nur bei weiterem Überschuß
Was passiert: die Bat1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummyzeit), das Reading Battery_ChargeRecommended_01 wird "1" gesetzt, d.h. die Bat01 soll mit voller Leistung geladen werden. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeRecommended_02 / 03 sind "0".
Ist das Ladeziel erreicht setzt man um die 2. Bat vollzuladen:
Die Bat01 / Bat03 unterliegen der Steuerung, d.h. Battery_ChargeRecommended_01 / 03 sind "0". Bat02 soll mit voller Leistung geladen werden -> Battery_ChargeRecommended_02 ist "1".
Ist auch die Bat02, würde man den Kelch an die Bat03 weiterreichen:
Der Vorteil des Setzens via attrKeyVal hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund gecheckt wird und ggf. ein Fehler zurückgegeben wird den der User im Script auswerten kann und damit die Fehlermöglichkeiten minimiert werden.
Um deine Idee aufzugreifen, wäre ein weiterer Schlüssel "lcBool=<Device>:<Reading>" denkbar, welches ein logisches true / false liefern kann, um die Ladung unter Modulkontrolle (1) bzw. ohne Modulkontrolle, d.h. mit voller Leistung (0) zu realisieren.
Die Verwendung von lcSlot und lcBool kann ich durch Prüfung gegeneinander ausschließen, d.h. der User kann nur eine der Varianten gleichzeitig setzen.
Das "lc" steht in diesen Schlüssel für "load control".
LG,
Heiko
Zitat"wäre es nicht besser das durch ein 'true'-'false' (als Reading) ggfls optional gefolgt von einem Zeitfenster (z.B.: true:10:53) zu steuern?" dann wäre einfach auch eine Reihenfolge in der Batterieladung (wenn mehr als eine Bat. vorhanden ist) realisierbar?Ob das besser wäre kommt ein bisschen darauf an welche Ziele man verfolgt. Ein bisschen weiter vorn war ein Nutzer der täglich bis zu einer bestimmten Zeit soviel in die Bat laden wollte wie es geht, danach sollte die Ladekontrolle greifen.
Momentan, wenn lcSlot nicht gesetzt ist, entspricht es im Prinzip deinem "false" sofern man darunter versteht dass das Lademanagement aktiv ist und eine Empfehlung per Reading steuert mit welcher Leistung geladen werden sollte. Das ist der default.
Nun kann man mit lcSlot die Steuerung nur auf einen täglichen Slot eingrenzen, in dem die Batterie der Steuerung vom Modul unterliegt, aber sonst mit der vollen möglichen Leistung geladen wird.
Wir haben momentan keinen Modus der das Laden quasi logisch "unterbindet", sondern mit 0 nur einschränkt (Laden bei Überschreitung eines Einspeiselimits) bzw. 1 Laden mit voller Leistung was möglich ist. Die Zeit außerhalb des Slots würde einem "true" entsprechen. Das bedeutet "true" -> immer Laden mit max. möglicher Leistung, "false" -> Laden unter Modulsteuerung.
Um ein von dir skizziertes Szenario mit z.B. 3 Batterien umzusetzen, könnte man so vorgehen:
1. die Bat 1 soll mit voller Leistung geladen werden, die anderen nur bei weiterem Überschuß
Code Auswählen
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
Was passiert: die Bat1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummyzeit), das Reading Battery_ChargeRecommended_01 wird "1" gesetzt, d.h. die Bat01 soll mit voller Leistung geladen werden. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeRecommended_02 / 03 sind "0".
Ist das Ladeziel erreicht setzt man um die 2. Bat vollzuladen:
Code Auswählen
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
Die Bat01 / Bat03 unterliegen der Steuerung, d.h. Battery_ChargeRecommended_01 / 03 sind "0". Bat02 soll mit voller Leistung geladen werden -> Battery_ChargeRecommended_02 ist "1".
Ist auch die Bat02, würde man den Kelch an die Bat03 weiterreichen:
Code Auswählen
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=23:00-23:10
Der Vorteil des Setzens via attrKeyVal hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund gecheckt wird und ggf. ein Fehler zurückgegeben wird den der User im Script auswerten kann und damit die Fehlermöglichkeiten minimiert werden.
Um deine Idee aufzugreifen, wäre ein weiterer Schlüssel "lcBool=<Device>:<Reading>" denkbar, welches ein logisches true / false liefern kann, um die Ladung unter Modulkontrolle (1) bzw. ohne Modulkontrolle, d.h. mit voller Leistung (0) zu realisieren.
Die Verwendung von lcSlot und lcBool kann ich durch Prüfung gegeneinander ausschließen, d.h. der User kann nur eine der Varianten gleichzeitig setzen.
Das "lc" steht in diesen Schlüssel für "load control".
LG,
Heiko
#6
ZWave / Shelly Qubino Wave 1 - Problem...
Letzter Beitrag von xl:bk - 23 Mai 2025, 21:57:15Hallo zusammen,
nachdem, wie in meinem anderen Thema besprochen, die ZWave Komponenten sehr gut funktionieren möchte ich doch teilweise meine alten Homematic-Aktuatoren durch ZWave ersetzen.
Hierfür habe ich mir mal einen Shelly Qubino Wave 1 besorgt, und tester gerade ein paar Funktionen.
Im Pinzip funktioniert alle soweit, nur bei einer Sonderfunktion wird der aktuelle Zustand / das Reading "state" nicht aktualisiert.
Wenn ich den Aktuator per FHEM oder über einen angeschlossenen Taster schalte, funktioniert alles wunderbar. Egal wie ein Schaltvorgangen ausgelößt wird, das Reading "state" enthält den jeweiligen Zustand des Relais. Auch die Funktionen "on-for-timer" oder "off-for-timer" funktionieren einwandfrei mit der richtigen Darstellung des Status.
Sobald aber am Aktuator ein "configTurnO1OFFAutomaticallyWithTimer" gesetzt wird (hierbei wird das Relais nach einer vorgegebenen Zeit ausgeschaltet), scheint der Aktator den Zustand nicht an FHEM zu senden.
Er bleibt dann im FHEM immer eingeschaltet, obwohl das das Relais im Aktuator nach der vorgegebenen Zeit wieder ausgeschaltet wurde. Hierbei ist es egal, ob das Einschalten über den angeschlossenen Taster oder FHEM erfolgt.
Wird der "configTurnO1OFFAutomaticallyWithTimer" wieder auf 0 gesetzt, funktioniert alles einwandfrei.
Jetzt kann ich leider nicht beurteilen, ob das Problem an FEHM liegt, oder ob die Firmware im Aktuator einen Fehler hat. Im Grunde ist das ja wirklich schon ein Sonderfall, mich würde trotzdem interessieren warum es nicht funktioniert.
Vielleicht gibt es eine Idee, wie man hier weiter kommen könnte...
nachdem, wie in meinem anderen Thema besprochen, die ZWave Komponenten sehr gut funktionieren möchte ich doch teilweise meine alten Homematic-Aktuatoren durch ZWave ersetzen.
Hierfür habe ich mir mal einen Shelly Qubino Wave 1 besorgt, und tester gerade ein paar Funktionen.
Im Pinzip funktioniert alle soweit, nur bei einer Sonderfunktion wird der aktuelle Zustand / das Reading "state" nicht aktualisiert.
Wenn ich den Aktuator per FHEM oder über einen angeschlossenen Taster schalte, funktioniert alles wunderbar. Egal wie ein Schaltvorgangen ausgelößt wird, das Reading "state" enthält den jeweiligen Zustand des Relais. Auch die Funktionen "on-for-timer" oder "off-for-timer" funktionieren einwandfrei mit der richtigen Darstellung des Status.
Sobald aber am Aktuator ein "configTurnO1OFFAutomaticallyWithTimer" gesetzt wird (hierbei wird das Relais nach einer vorgegebenen Zeit ausgeschaltet), scheint der Aktator den Zustand nicht an FHEM zu senden.
Er bleibt dann im FHEM immer eingeschaltet, obwohl das das Relais im Aktuator nach der vorgegebenen Zeit wieder ausgeschaltet wurde. Hierbei ist es egal, ob das Einschalten über den angeschlossenen Taster oder FHEM erfolgt.
Wird der "configTurnO1OFFAutomaticallyWithTimer" wieder auf 0 gesetzt, funktioniert alles einwandfrei.
Jetzt kann ich leider nicht beurteilen, ob das Problem an FEHM liegt, oder ob die Firmware im Aktuator einen Fehler hat. Im Grunde ist das ja wirklich schon ein Sonderfall, mich würde trotzdem interessieren warum es nicht funktioniert.
Vielleicht gibt es eine Idee, wie man hier weiter kommen könnte...
#7
MQTT / Aw: subscribe_Reading in DoIf ...
Letzter Beitrag von betateilchen - 23 Mai 2025, 20:50:17Warum möchte man sowas in einem DOIF machen?
Für MQTT/JSON gibt es doch tatsächlich andere/spezialisiertere Lösungen in FHEM.
Für MQTT/JSON gibt es doch tatsächlich andere/spezialisiertere Lösungen in FHEM.
#8
Sonstiges / Aw: RenaultZE
Letzter Beitrag von JJ_Pamoux - 23 Mai 2025, 19:55:49Zitat von: plin am 20 Mai 2025, 14:47:15mmh, und wie kommt der individuelle Google API key in den code?Mit dem Texteditor deiner Wahl.
Ja, das ist bei mir kein Parameter, allerdings weiß ich auch überhaupt nicht, ob das etwas für das Hauptmodul wäre, ich wollte das nur ein bisschen als Idee teilen.
Wenn das interessant ist, dann kann ich das gerne auch noch einmal als ordentlichen Patch aufbereiten. Nutze das Modul sehr gerne, echt sehr praktisch!
#9
MQTT / subscribe_Reading in DoIf Devi...
Letzter Beitrag von appi - 23 Mai 2025, 19:49:02Hallo
ich bin am Ende meiner Kenntnisse.....
Ich möchte in einem DoIF Device mit subscribe_Reading ein MQTT JSON String aufsplitten und einzelne Readings erzeugen. Leider klappt es nicht und ich wäre wiedermal um einen Tipp dankbar.
Die MQTT JSON MessaGE sieht so aus:
Mein subscribe_Reading:
Ergibt:
{"event":"up","val":7}
Wie kriege ich nur den Wert von val mit dem Readingname p2b91_val? Also p2b91_val = 7
Danke für einen Tipp
gruss
ich bin am Ende meiner Kenntnisse.....
Ich möchte in einem DoIF Device mit subscribe_Reading ein MQTT JSON String aufsplitten und einzelne Readings erzeugen. Leider klappt es nicht und ich wäre wiedermal um einen Tipp dankbar.
Die MQTT JSON MessaGE sieht so aus:
Code Auswählen
p2b91 = {"event":"up","val":8} Mein subscribe_Reading:
Code Auswählen
Fan_Speed:topic=hasp/plate_3/state/p2b91 Fan_Speed:expression={"val"=>$value}Ergibt:
{"event":"up","val":7}
Wie kriege ich nur den Wert von val mit dem Readingname p2b91_val? Also p2b91_val = 7
Danke für einen Tipp
gruss
#10
MQTT / Aw: [gelöst] MQTT Ansatz für P...
Letzter Beitrag von cluberer99 - 23 Mai 2025, 19:34:36Hallo,
ich hab derzeit ein kleines Problem das ganze wieder ans laufen zu bekommen. Nach der Erstinstallation lief alles für ca. 1,5 Stunden, dann kamen keine Daten mehr. Auch eine erneute Installation brachte keinen erfolg. Für die Datenabfrage nutze ich einen Zweiten Account, dieser sieht über die App auch die aktuellen Daten, wenn ich mich neu einlogge. Starte ich das Script kommt bei der APP eine Fehlermeldung das ein anderes Gerät angemeldet bereits angemeldet ist. Wenn ich das Script manuell starte kommt eine Fehlermeldung (Screenshot)
Eventuell kann mir einer bei dem Problem helfen.
ich hab derzeit ein kleines Problem das ganze wieder ans laufen zu bekommen. Nach der Erstinstallation lief alles für ca. 1,5 Stunden, dann kamen keine Daten mehr. Auch eine erneute Installation brachte keinen erfolg. Für die Datenabfrage nutze ich einen Zweiten Account, dieser sieht über die App auch die aktuellen Daten, wenn ich mich neu einlogge. Starte ich das Script kommt bei der APP eine Fehlermeldung das ein anderes Gerät angemeldet bereits angemeldet ist. Wenn ich das Script manuell starte kommt eine Fehlermeldung (Screenshot)
Code Auswählen
[2025-05-23T17:29:16.922Z] {"username":"+++","password":"***","country":"DE","loginStore":"auth.data","pollInterval":60,"mqttUrl":"mqtt://localhost:1883","mqttClientId":"solix2mqtt","mqttRetain":false,"mqttTopic":"solix","verbose":true}
[2025-05-23T17:29:16.939Z] Fetching data
[2025-05-23T17:29:16.973Z] Using cached auth data
[2025-05-23T17:29:16.974Z] ++++
[2025-05-23T17:29:16.979Z] {}
[2025-05-23T17:29:17.644Z] Failed fetching or publishing printer data AggregateError [ECONNREFUSED]:
at internalConnectMultiple (node:net:1139:18)
at afterConnectMultiple (node:net:1714:7) {
code: 'ECONNREFUSED',
[errors]: [
Error: connect ECONNREFUSED ::1:1883
at createConnectionError (node:net:1677:14)
at afterConnectMultiple (node:net:1707:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 1883
},
Error: connect ECONNREFUSED 127.0.0.1:1883
at createConnectionError (node:net:1677:14)
at afterConnectMultiple (node:net:1707:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 1883
}
]
}
[2025-05-23T17:29:17.662Z] Sleeping for 59276ms...
Die Zeile "Error: connect ECONNREFUSED ::1:1883" sieht für mich merkwürdig aus. Eventuell kann mir einer bei dem Problem helfen.