Bug: Heatpump switch not turned off
Closed this issue · 38 comments
Describe the bug
I have a device configured as heat pump type. It turns on the switch data point properly with start of the designated time window but does not turn off at the end of the time window or in any other case.
Expected behavior
Device should turn off triggered by SHM and at the end of the time window
Screenshots & Logfiles
- SAE device configuration
- Screenshots in SHM
- Log of data point
Versions: - Adapter version: v0.0.1
- Node version: v16.17.0
SAE device configuration
Data point
Data point history (I switched it off manually at 17:48 since this did not happen automatically)
SHM
I see the same behavior (sometimes) in my test setup as well. Other users are also reporting the problem... I'm trying to find a solution already...
Great, thanks for letting me know.
with current version here in github problem should be solved
with current version here in github problem should be solved
Okay, v 0.0.2? How must it be installed to keep the configuration?
just install it from here:
Any news when the turn-off recognition and possibly a manual switch would be available? Thanks!
in latest version an option is available, to switch off a device at the end of possible run time:
on the other side you can switch off a device anytime manually. There is no need to do so in the adapter...
regarding turn-off recognition please check SMA docu https://github.com/rg-engineering/ioBroker.semp/blob/master/docu/SMA/SEMP-11ZE3315-Specification-1.0.6.pdf on page 43.
They say at the end of operation there is no switch off recommendation necessary. The device itself should switch off. I've implemented that here in the adapter. Whenever we reach MaxRunningTime I switch the device off...
Yes, I just updated and saw that new checkbox. This is relating to the predefined runtime or the end of the time window?
Regarding turnoff signals, devices do not send turnoff signals when they did not run at all.
Let's imagine the window opens at 9:00 and it's planned end is 12:00. At 9:00 the Semp switches turns on and thereby sets the SG ready port of the heatpump to true.
However the heatpump does not run because no warm water is needed or heating is not necessary.
Then the window stays open until 12:00 o'clock and all the energy the could have been used for other devices is wasted.
This is why I say we need a turned-off recognition that closes the window prematurely at e.g. 9:10 if the power counter does not show any load at this time.
This should free up time from 9:10 to 12:00 for other devices.
Regarding manual switch - with semp devices there is no manual switch in the SMA app. And if you switch e.g. with HomeKit or fritz app, the original state is set by SHM within minutes. Practically I cannot manually turn on the dishwasher anymore when it's configured in SEMP adapter as a device :-(.
This is relating to the predefined runtime or the end of the time window?
end of time window. at the end of predefined runtime I switche the device off in any case.
Regarding turnoff signals
this clear but not yet implemented. I spent a lot of time to find out why (sometimes) the device was not switched off. This is now clear with the explanation in SMA docu.
And if you switch e.g. with HomeKit or fritz app, the original state is set by SHM within minutes
does it mean you get off-recommendation from SHM when you switch on the device manually without on-recommendation?
This is relating to the predefined runtime or the end of the time window?
end of time window. at the end of predefined runtime I switche the device off in any case.
Ok
Regarding turnoff signals
this clear but not yet implemented. I spent a lot of time to find out why (sometimes) the device was not switched off. This is now clear with the explanation in SMA docu.
**Yes, the SHM continues to send turn on signals until the end of the time window. That does not make sense if the device does not WANT to switch on. Better to close the time window prematurely and assign the Gained time to another device like the Wallbox. **
And if you switch e.g. with HomeKit or fritz app, the original state is set by SHM within minutes
does it mean you get off-recommendation from SHM when you switch on the device manually without on-recommendation?
**Exactly, it is then a fight and the the SHM does not stop. See logic described above, that's the reason.
You can only solve this by deleting the time window. Maybe it makes sense to implement a switch for that cases.
**
with latest version (just uploaded) the cancelation of energy request should work in case the device doesn't turn on.
I cancel the request at SHM and turn off the data point for the device switch (set to false).
The case where we want a cancelation when device was on and switches off earlier then expected is not implemented yet.
Thanks a lot! I just installed it and planned 1h time windows for tomorrow to test:
Let's see how it goes :-).
One thing, it seem that read-only devices without a switch and Energieanforderung throw an error:
oh yes, the problem appears on devices without planning requests... will fix it tomorrow...
Unfortunately, I had no no switch-on today of the switch. Any idea what might be the problem?
do you have csv logging enabled? may I have the log to analyze?
I would provide it if I knew where the log file is stored.
Is it the home folder on the synology or within the IOB container?
it's a path within the IOB container, but you must configure it. I guess /home/pi/ is not available on your system...
in my case:
but please use latest version from github...
Got it :-). Will report back tomorrow night. Thanks a lot.
Here is the protocol - I see some strange behaviour. The switch goes to true and after 53 seconds back to false multiple times.
The reaction of the datapoint shows the same behaviour
in general the csv looks good to me: The SHM tries to switch on the device every hour, sometimes the device follows, sometimes not. If the device not follows, then the timeframe disappears from the list, this is what we want...
strange is that the device sometimes does not follow turn off command, means we get a turn off recommendation and device remain on.
The on / off behaviour from your picture above I can not see in csv. I only see e.g. at 14:20 a turn on recommendation from SHM which should lead to an on state of switch. I can not explain why the switch then goes off. Eventually we can see it in iob log...
What do mean by device?
You mean the value in the field "Object-ID Status", right?
This is in my case the Boolean value (true/false) of the heatpump compressor.
So it is only true when the heatpump runs, and as it is an SG ready heatpump it is normal that it might noch react immediately when the OBject-ID switch changes values.
Why do you think it is normal that the true value can change after only 50 seconds back to false?
I would expect it to stay true for 10 minutes waiting time in case the heatpump wants to turn on.
it is normal that it might noch react immediately
okay, if so then we can leave it as it is, and you are right the message from SHM is an "recommendation" and SMA doc says it "should" follow..
Why do you think it is normal that the true value can change after only 50 seconds back to false?
I'm not saying it's normal, I just can't explain why it is. We may see an explanation in the IOB log...
okay, if so then we can leave it as it is, and you are right the message from SHM is an "recommendation" and SMA doc says it "should" follow..
Yes. And I believe the cancelation of windows really works. I see that the time window 13:00 - 14:00 is already cancelled and the next 14:00 - 15:00 is still planned.
I'm not saying it's normal, I just can't explain why it is. We may see an explanation in the IOB log...
You mean I should switch the SEMP adapter protocol to silly and post this here?
Btw. I recognized today that the 10 minutes waiting time after the full hour until cancelation of the time window is really there. However within these 10 minutes I observe true/false switching every 50 seconds. This seems to be a bug still.
You mean I should switch the SEMP adapter protocol to silly and post this here?
yes, please enable debug logging for the SEMP adapter. You can post the log here or send it by email to info@rg-engineering.eu
Ok, I just sent you todays protocol.
Unfortunately, I did not see a true status for the switch the whole day.
Maybe, the SEMP or SHM thought not enough PV energy produced today?
There is no "must" run functionality implemented yet, right?
You can force a "must run" with MinRunningTime > 0. The difference between MaxRunningTime and MinRunningTime is optional. A better description you can find in SEMP-11ZE3315-Specification-1.0.6.pdf on page 43 . The file is available in docu/SMA folder here in the repository.
and yes, also in the log there is no true state for the switch and so I'm not able to identify the root cause for toggling.
btw. please disable "extended logging", this is not necessary actually.
okay, so the minimum runtime must be specified in the time wondows not on the main page right? There I had it set for 30 minutes. So set it for 5 Min each timewindow? This is a bit against a senseful logic. I would force the heatpump every h to switch on for minimum 5 minutes even though there is no sun. This minimum runtime should go across all time windows not applicable for each timewindow separately...
So what do we do about the constant toggling between true and false? Am I the only one with this behaviour?
okay, so the minimum runtime must be specified in the time wondows not on the main page right?
On the main window the settings are related to interruptions! If you disable "interruptions allowed" those settings disappear...
There I had it set for 30 minutes. So set it for 5 Min each timewindow? This is a bit against a senseful logic.
why? here we are talking about two different things (interruptions and minimum non-optional energy) ... (again please have a look on detailed description from SMA referenced on my previous post)
This minimum runtime should go across all time windows not applicable for each timewindow separately...
yes, in your case. but others might have different ideas, so I think it must be adjustable per timeframe
So what do we do about the constant toggling between true and false?
I need a IOB debug log file to analyze it when it happens again.
Am I the only one with this behaviour?
there are no other reports up to now...
Yes, sorry - I am not putting enough time into reading the standard documentation - I am currently fixing a problem with our PV system which takes a lot of time.
On the main window the settings are related to interruptions! If you disable "interruptions allowed" those settings disappear...
Ok, this functionality refers to each time window separately right? That means the switch could be turned on and off within my 1 h time windows. I would rather turn it off to bring more stability in our system.
why? here we are talking about two different things (interruptions and minimum non-optional energy) ... (again please have a look on detailed description from SMA referenced on my previous post)
I checked the SEMP guide. I wonder if it is good to have multiple 1h time windows spread across the day, if I understand the logic of SHM correctly.
E.g. I need the heatpump to run minimum 2h a day to heat and for warm water. In case, interruptions allowed flag is set, it would possibly split the runtime in 2x1h. If the flag is not set, it would have it run 1x2h a day.
If I have now 7 time windows, e.g. from 9:00 to 16:00, would the SHM be able to handle this and run the two scenarios 2x1h and 1x2h?
Since I have to set the minimum run time for each time window separately, I cannot tell it to run the required 2h in total, because I cannot set the 2h across all time windows.
If the statement above is correct, I would revert back to setting up one long time windows from 9:00 - 16:00 with 2h minimum runtime for the heatpump. However, this brings back the problem, that the detection function for the heat pump is only activated at the beginning of the time window. As a consequence, e.g. the time window opens at 9:00 and turn on recommendation is set, but the heat pump does not turn on yet. So the time window is closed at 9:10 and not reopened for the whole day.
In this case, it might be better, to keep the time window open and allow turn-on signals in frequent definable intervals (e.g. every hour) from SHM und suppress all other turnon signals.
I need a IOB debug log file to analyze it when it happens again.
Let me run some more tests over hear to test some things.
Btw. is the "semp.0.Devices.Wärmepumpe_Semp_221029.RecommendedState" behaving in the same way like the Object-ID-Switch? I guess you implemented the Object-ID-Switch field so that users can steer a device directly not having to go through a Node red script, right?
I see your problem but I don't have the perfect answer.
If I assume the device (heatpump) just follows the recommendation of SHM then it's easy: setup a long time period with a minimum running time of 2 hours and disable option "cancel request if device does not switch on" / "Anforderung abbrechen, wenn Gerät nicht einschaltet". Interruptions may then allowed or not. In those cases the SHM calculates exactly minimum 2 hours during time frame where the heatpump can run.
In cases where the device (heatpump) does not necessarily follows the recommendation of SHM it becomes more difficulty. In those cases the SHM calculates and predicts a time frame to operate. If the device does not use it the SHM wil not try it again in the same time frame. In that cases I thing a few time frames could overcome that problem. From my experience we can not force the SHM to try to turn on a device lets say every hour. We have seen it in many logs: the SHM wants to turn on a device and if the device does not turn on then the SHM sends the recommendation again and again every minute...
The data point "RecommendedState" is read only. It just shows the last recommendation of SHM for the device. There is no action implemented if you try to change the value... Is your idea to change that datapoint and device OID-switch should follow?
How about this approach:
I set up a long time period with minimum running time of 2 hours but activate a new option called "suppress request for ... minutes if device does not switch on" / "Anforderung für ... Minuten unterdrücken, wenn Gerät nicht einschaltet".
In this new option, SEMP would wait for the defined "probation" time for the heatpump to switch on, e.g. 10 minutes. After that SHM would be allowed to send switch on recommendation throughout the whole time window but those are suppressed by SEMP for a predefined time, e.g. 60 minutes. After this time, switch on recommendations can pass again for the prefined "probation" time. If the heatpump then switches on, great. If not, switch on reommendations are suppressed again for 60 minutes.
In this scenario, would SHM switch on other devices during the suppression times so that PV energy is used for other devices than the heatpump?
Regarding RecommendedState, okay then it is not the same like the switch in SEMP itself.
Could be an idea...
Do you know how SmartApplianceEnabler handles that scenario?
SAE works the same as SEMP... with multiple time windows you can set-up and only one "max. Zeit zum Einschalten nach Empfehlung [Minuten]" trigger. So it is basically the same problem, if you set-up multiple time windows per day, you cannot set the correct total minimum run-time, if you set-up one long time window instead one trigger "max. Zeit zum Einschalten nach Empfehlung [Minuten]" is not enough as the heatpump might want to switch on a little later.
So, I would propose to allow repetitive turn-ons + checks per time window.
Btw. this semp.0.Devices.Wärmepumpe_Semp_221029.RecommendedState field, is it reflecting when SHM sends a turn-on command? I see very little activity in the history log on this datapoint. I looks like I get hardly ever a turn-on command from SHM even though PV-consumption level is set only to 30%.
@rg-engineering Any ideas how to solve the issue described in my last post?
Btw. did you manage to correct the error with devices without switch and Timewindows?
@rg-engineering After some weeks of testing I am not convinced of the current software state - sorry to say.
The Switch Own Recommendation goes on true at 9:00 and turns off at 16:00. No real interaction. I think I try the SAE for some time to check if it works better :-(.
Would be great to see what SAE can do better and how.
Let's hope, I will test and report back. Maybe it is my settings but I don't know where to look right now. Today, again no real results - eventhough results are distorted due to bad weather:
@stevoboy Können wir das hier schliessen, oder hast du neue Erkenntnisse?