- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
Automatisierung / Aw: ASC: readingsProxy ist nic...
Letzter Beitrag von Beta-User - 14 Februar 2026, 16:51:12Zitat von: CoolTux am 14 Februar 2026, 15:40:53Hallo,Wo genau soll das Problem liegen?
Ein readingsproxy dient eigentlich dazu immer nur ein reading aus einem Device zu nehmen und separat da zu stellen. Damit kann ASC nicht zusammen arbeiten.
"Eigentlich" sollte ein einziges Reading doch ausreichen, solange es numerisch ist...
Der erste Schritt wäre jedenfalls mal, das list von einem der readingsProxy zu zeigen...
#12
Automatisierung / Aw: ASC: readingsProxy ist nic...
Letzter Beitrag von CoolTux - 14 Februar 2026, 16:43:19Damit kann ASC in der Tat nicht umgehen, hier wirst Du Dir wohl eine Art Wrapper programmieren müssen befürchte ich. Oder das ROLLO Modul hat hier vielleicht Möglichkeiten.
#13
Automatisierung / Befehl an Shelly erneut senden...
Letzter Beitrag von Hadl - 14 Februar 2026, 16:17:14Hallo zusammen,
ich nutze einen Shelly um mein Warmwasser bei PV Überschutz zu erhitzen.
Das klappt auch mit einem etwas komplexeren DOIF sehr gut. Der DOIF schaltet an dem Shelly dann einen oder beide Ausgänge mit Heizstäben je nach Überschuss ein und aus.
Manchmal hat aber der Shelly scheinbar keine WLAN verbindung und ein Kommando geht verloren. Das ist besondes ärgerlich wenn es das letze Ausschalten vor Sonnenuntergang ist, denn dann läuft der Heizstab einfach weiter und heizt bis Maximaltemperatur.
Den Shelly steuere ich über das Shelly Modul
1kW-ein:1kW-aus:2kW-ein:2kW-aus
Ich wünsche mir nun eine Funktion die das Shelly Kommando solange wiederholt bis es erfolgreich empfangen wurde. Kann man das mit dem Shelly Modul selbst hinbekommen?
Falls nicht, kann ich irgendwie einen Soll/Ist Vergleich der Relais Zustände machen und das Kommando bei Abweichung wiederholen?
Vielen Dank für eure Ideen
Hadl
ich nutze einen Shelly um mein Warmwasser bei PV Überschutz zu erhitzen.
Das klappt auch mit einem etwas komplexeren DOIF sehr gut. Der DOIF schaltet an dem Shelly dann einen oder beide Ausgänge mit Heizstäben je nach Überschuss ein und aus.
Manchmal hat aber der Shelly scheinbar keine WLAN verbindung und ein Kommando geht verloren. Das ist besondes ärgerlich wenn es das letze Ausschalten vor Sonnenuntergang ist, denn dann läuft der Heizstab einfach weiter und heizt bis Maximaltemperatur.
Den Shelly steuere ich über das Shelly Modul
Code Auswählen
defmod ShellyBoiler Shelly 192.168.178.xx
attr ShellyBoiler event-min-interval .*:3600
attr ShellyBoiler event-on-change-reading .*
attr ShellyBoiler eventMap /on 0:1kW-ein/off 0:1kW-aus/on 1:2kW-ein/off 1:2kW-aus
attr ShellyBoiler icon sani_buffer_electric_heater_side
attr ShellyBoiler interval 60
attr ShellyBoiler mode relay
attr ShellyBoiler model shellyplus2pm
attr ShellyBoiler stateFormat 1kW:relay_0\
<br>\
2kW:relay_1
attr ShellyBoiler userReadings power_sum:power_.* {my $val = ReadingsVal($name,"power_0",0) + ReadingsVal($name,"power_1",0);;;;$val},\
energy_sum:energy_.* {my $val = ReadingsVal($name,"energy_0",0) + ReadingsVal($name,"energy_1",0);;;;$val},
attr ShellyBoiler webCmd 1kW-ein:1kW-aus:2kW-ein:2kW-aus
attr ShellyBoiler webhook WEB
setstate ShellyBoiler 1kW:off\
<br>\
2kW:offDer DOIF ruft diese Kommandos hier auf:1kW-ein:1kW-aus:2kW-ein:2kW-aus
Ich wünsche mir nun eine Funktion die das Shelly Kommando solange wiederholt bis es erfolgreich empfangen wurde. Kann man das mit dem Shelly Modul selbst hinbekommen?
Falls nicht, kann ich irgendwie einen Soll/Ist Vergleich der Relais Zustände machen und das Kommando bei Abweichung wiederholen?
Vielen Dank für eure Ideen
Hadl
#14
Automatisierung / Aw: ASC: readingsProxy ist nic...
Letzter Beitrag von piet_pit - 14 Februar 2026, 15:56:16Hallo und guten Tag Cooltux,
vielen Dank für deine Info und Hilfe. Hier ein weiterer Thread, der das Problem schildert, auch der Vorschlag von Beta-User mit dem readingsproxy führt leider nicht zum Ziel.
https://forum.fhem.de/index.php?topic=142739.0
Für die Aktivierung der beiden Kanäle ist folgende Syntax notwendig:
Für Kanal 1
Damit so wie ich das verstehe, kann ASC nicht umgehen.
Viele Grüße
Pit
vielen Dank für deine Info und Hilfe. Hier ein weiterer Thread, der das Problem schildert, auch der Vorschlag von Beta-User mit dem readingsproxy führt leider nicht zum Ziel.
https://forum.fhem.de/index.php?topic=142739.0
Für die Aktivierung der beiden Kanäle ist folgende Syntax notwendig:
Für Kanal 1
Code Auswählen
set <name> pct 50 1Für Kanal 2Code Auswählen
set <name> pct 50 0Damit so wie ich das verstehe, kann ASC nicht umgehen.
Viele Grüße
Pit
#15
FHEM Code changes / Revision 30846: 76_SolarForeca...
Letzter Beitrag von System - 14 Februar 2026, 15:50:56Revision 30846: 76_SolarForecast: contrib Version 2.2.0
76_SolarForecast: contrib Version 2.2.0
Source: Revision 30846: 76_SolarForecast: contrib Version 2.2.0
76_SolarForecast: contrib Version 2.2.0
Source: Revision 30846: 76_SolarForecast: contrib Version 2.2.0
#16
FHEM Code changes / Revision 30845: 76_SolarForeca...
Letzter Beitrag von System - 14 Februar 2026, 15:50:56Revision 30845: 76_SolarForecast: contrib Version 2.2.0
76_SolarForecast: contrib Version 2.2.0
Source: Revision 30845: 76_SolarForecast: contrib Version 2.2.0
76_SolarForecast: contrib Version 2.2.0
Source: Revision 30845: 76_SolarForecast: contrib Version 2.2.0
#17
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 14 Februar 2026, 15:45:23@Parallix, @all,
ConsumerXX->mode kann nun auch den Wert 'mustNot' erhalten. Dadurch kann ähnlich wie bei type 'noSchedule' die Planung verhindert werden.
Allerdings kann 'mode' auch gut dynamisch über Device:Reading geändert werden. Ist die Planung bereits erfolgt aber der Consumer noch nicht gestartet, wird die Planung zurückgenommen.
Ist der Consumer bereits gestartet, wird er gestoppt und die Planung zurückgenommen. Wird der mode von 'mustNot' auf 'can' oder 'must' geändert, ist mit "set ... consumerNewPlanning" eine Neuplanung nötig oder man wartet bis zur nächsten automatischen Einplanung.
Die V 2.2.0 liegt im contrib zum Test.
LG
ConsumerXX->mode kann nun auch den Wert 'mustNot' erhalten. Dadurch kann ähnlich wie bei type 'noSchedule' die Planung verhindert werden.
Allerdings kann 'mode' auch gut dynamisch über Device:Reading geändert werden. Ist die Planung bereits erfolgt aber der Consumer noch nicht gestartet, wird die Planung zurückgenommen.
Ist der Consumer bereits gestartet, wird er gestoppt und die Planung zurückgenommen. Wird der mode von 'mustNot' auf 'can' oder 'must' geändert, ist mit "set ... consumerNewPlanning" eine Neuplanung nötig oder man wartet bis zur nächsten automatischen Einplanung.
Die V 2.2.0 liegt im contrib zum Test.
LG
#18
Automatisierung / Aw: ASC: readingsProxy ist nic...
Letzter Beitrag von CoolTux - 14 Februar 2026, 15:40:53Hallo,
Ein readingsproxy dient eigentlich dazu immer nur ein reading aus einem Device zu nehmen und separat da zu stellen. Damit kann ASC nicht zusammen arbeiten. ASC benötigt das tatsächliche Rollo Device oder etwas vergleichbares. Es gibt doch dieses Modul ROLLO. Damit sollte doch so einige s möglich sein denke ich.
Aber wieso genau gehst Du überhaupt über readingsproxy und nimmst nicht direkt das Device welches das Rollo steuert.
Ein readingsproxy dient eigentlich dazu immer nur ein reading aus einem Device zu nehmen und separat da zu stellen. Damit kann ASC nicht zusammen arbeiten. ASC benötigt das tatsächliche Rollo Device oder etwas vergleichbares. Es gibt doch dieses Modul ROLLO. Damit sollte doch so einige s möglich sein denke ich.
Aber wieso genau gehst Du überhaupt über readingsproxy und nimmst nicht direkt das Device welches das Rollo steuert.
#19
MQTT / Aw: MQTT_GENERIC_BRIDGE: [mqtt...
Letzter Beitrag von rudolfkoenig - 14 Februar 2026, 15:05:04Ich kenne weder MQTT_GENERIC_BRIDGE noch THZ richtig, mein Beitrag ist also mit Vorsicht zu lesen.
Soweit ich MQTT_GENERIC_BRIDGE versetehe, kommt diese Meldung dann, wenn der set Befehl was zurueckliefert, was generell als Fehler zu werten ist.
Die Fehlermeldung ist in diesem Fall "11 °C"
Leider protokolliert weder MQTT_GENERAL_BRIDGE, noch THZ den Befehl, ich empfehle deswegen in FHEM/00_THZ.pm nach Zeile 1181 in der Funktion THZ_Set eine Zeile wie
Dann weiss man genau, was der Befehl war, und man kann per direktes Setzen aus FHEM aus rauskriegen, was erwuenscht ist.
Soweit ich MQTT_GENERIC_BRIDGE versetehe, kommt diese Meldung dann, wenn der set Befehl was zurueckliefert, was generell als Fehler zu werten ist.
Die Fehlermeldung ist in diesem Fall "11 °C"
Leider protokolliert weder MQTT_GENERAL_BRIDGE, noch THZ den Befehl, ich empfehle deswegen in FHEM/00_THZ.pm nach Zeile 1181 in der Funktion THZ_Set eine Zeile wie
Code Auswählen
Log3 $hash->{NAME}, 3, "THZ set ".join(@a);
einzufuegen, FHEM neu zu starten, das Experiment zu wiederholen, und im FHEM Log nach "THZ set" zu suchen.Dann weiss man genau, was der Befehl war, und man kann per direktes Setzen aus FHEM aus rauskriegen, was erwuenscht ist.
#20
Automatisierung / ASC: readingsProxy ist nicht A...
Letzter Beitrag von piet_pit - 14 Februar 2026, 14:35:35Hallo und einen guten Tag Cooltux,
ich nutze schon seit vielen Jahren dein tolles ASC-Modul, alle Rolläden in unserem Haus laufen über dieses Modul, bis auf das Dachgeschoss
. In allen Rolläden sind Shellys verbaut, die über das Shelly-Modul in FHEM eingebunden sind. Im Dachgeschoss ist nun ein ShellyProDualCover/ Shutter neu verbaut, der zwei logische Kanäle bereitstellt. Diese Kanäle habe ich über das Modul "readingsproxy" angebunden und kann so die Rolläden auch steuern. Nur die Einbindung in ASC klappt einfach nicht.
Es kommt als Fehlermeldung:
Bleibt mir jetzt nur der Weg über ein Dummy?
Vielen Dank und viele Grüße
Pit
ich nutze schon seit vielen Jahren dein tolles ASC-Modul, alle Rolläden in unserem Haus laufen über dieses Modul, bis auf das Dachgeschoss
. In allen Rolläden sind Shellys verbaut, die über das Shelly-Modul in FHEM eingebunden sind. Im Dachgeschoss ist nun ein ShellyProDualCover/ Shutter neu verbaut, der zwei logische Kanäle bereitstellt. Diese Kanäle habe ich über das Modul "readingsproxy" angebunden und kann so die Rolläden auch steuern. Nur die Einbindung in ASC klappt einfach nicht.Es kommt als Fehlermeldung:
Code Auswählen
Dachgeschoss_Rollo_Hinten: unknown attribute ASC_PosCmd. Type 'attr Dachgeschoss_Rollo_Hinten ?' for a detailed list.Ist das richtig, dass AutoShuttersControl ASC_* Attribute nur bei unterstützten Device-Typen unterstützt, ein readingsProxy aber leider nicht dazu gehört?Bleibt mir jetzt nur der Weg über ein Dummy?
Vielen Dank und viele Grüße
Pit