I can confirm. This is mandatory to turn off if you rely on external sensors.
Otherwise it can behave strange. And the built-in detection adn its reactions is quite slow, logically.
Thank you, I checked, turning off detection does not change anything still the same symptoms
Are you sure the setting has been transmitted to the thermostat? Is it reflected in the UI after restarting HA? What happens if you disable Schedy altogether, set the thermostat to some value (not OFF) manually and then turn of a window? If the detection was really turned off, it should stay at the set temperature even after, let’s say, 15 minutes.
Yes, even in the logs you can not see the reaction see the logs from below in the first reaction immediately after restarting HA.
2019-09-06 11:07:22.986889 INFO schedy_heating: --> Attribute 'state' of 'binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor' changed from 'off' to 'on', reevaluating <Room R:living>.
2019-09-06 11:07:23.213792 INFO schedy_heating: <-- [R:living] Value set to OFF. [scheduled]
2019-09-06 11:07:24.694586 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2] Received value of OFF.
2019-09-06 11:07:26.061901 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3] Received value of OFF.
Now I open after a few minutes of inactivity and we have notified the opening and silence … then after a few minutes I manually increase the temperature on the thermostat and after a while gives the thermostats off
2019-09-06 11:16:23.215498 INFO schedy_heating: --> Attribute 'state' of 'binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor' changed from 'off' to 'on', reevaluating <Room R:living>.
2019-09-06 11:19:25.733979 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2] Received value of 24.0��.
2019-09-06 11:19:25.739387 INFO schedy_heating: --- [R:living] Propagating the change to all actors in the room.
2019-09-06 11:19:25.871927 INFO schedy_heating: <-- [R:living] Value set to 24.0��. [manual]
2019-09-06 11:19:25.877807 INFO schedy_heating: --- [R:living] Re-applying the schedule not before 11:20:25 (in 0:01:00).
2019-09-06 11:19:27.431693 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3] Received value of 24.0��.
2019-09-06 11:20:25.241130 INFO schedy_heating: <-- [R:living] Value set to OFF. [scheduled]
2019-09-06 11:20:26.732063 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2] Received value of OFF.
2019-09-06 11:20:28.126523 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3] Received value of OFF.
As it turns off the scheady and we have turned off detection on thermostats it is as it should be or window open thermostats normally turned on.
Wait, the config you posted above doesn’t show a schedule for the room living apart from the schedule_prepend section. Do you have one at all?
I wouldn’t need to ask if you uploaded a debug log somewhere…
no schedule, i just don’t need it.
Ah, than it’s clear what happened. When the window is closed, the only rule you have evaluates to Skip(), which causes schedule evaluation to produce no result. Now there is nothing for Schedy to restore. Please have a look at the OVERLAY_REVERT_ON_NO_RESULT result marker, which you have to apply as well.
I never tested such a scenario and am thus interested in how that goes for you.
Thank you I changed… now my configuration looks like this. Nothing has changed.
chedy_heating: # This is our app instance name.
module: hass_apps_loader
class: SchedyApp
actor_type: thermostat
# expression_environment: |
# def heating_mode():
# return state("input_select.heating_mode")
schedule_prepend:
- x: "Mark(OFF, Mark.OVERLAY_REVERT_ON_NO_RESULT) if not is_empty(filter_entities('binary_sensor', state='on', window_room=room_name)) else Skip()"
rooms:
living:
rescheduling_delay: 1
actors:
climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat:
max_temp: 24
climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2:
max_temp: 24
watched_entities:
- binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor
See the docs. You need to apply both markers.
@szumi83 I recently reworked the overlay handling and made the code simpler. The OVERLAY_REVERT_ON_NO_RESULT marker is no longer needed. If you want to try it out, that would be great. The URL you have to put into your addon config / pip command / requirements.txt (don’t know what install method you used) is:
https://github.com/efficiosoft/hass-apps/archive/overlay-rework.zip
Regards
Robert
super check and let you know. many thanks: D
ok, I add to the requirements.txt the link that you follow instead of hass-apps restarting and how can I check if I have what it is about? I’m using HassOS 2.12. end AppDaemon from Community Hass.io Add-ons
Do I change anything in the configuration?
Now I have
schedule_prepend:
- x: "Mark (OFF, Mark.OVERLAY) if not is_empty (filter_entities ('binary_sensor', state = 'on', window_room = room_name)) else Abort ()"
Well, Next() would be semantically more appropriate than Abort() in your case, but it should make no difference in the outcome. Just turn debug logging on and observe if your use case now works.
I changed the config as you suggested on Next () and it’s still not correct all the time.
How can I check if I have versions after changes?
I have added to the AppDaemon configuration (below the config) link to the corrected version and now I see that it is downloaded at startup but I still don’t know if I’m actually working on the new code.
{
"disable_auto_token": false,
"system_packages": [],
"python_packages": [
"https://github.com/efficiosoft/hass-apps/archive/overlay-rework.zip"
],
"log_level": "debug"
}
I attach a link to the debug log
https://1drv.ms/u/s!AovBANK6qDEvkTqDD2IRw2ZFteqP
This debug log you linked wasn’t created with the changed version. If it was, there wouldn’t be the error about Next being not defined. Could it be that you created the log before changing the appDaemon config?
EDIT: And please, use debug: true in the Schedy config instead of setting log_level = "debug" for the whole AppDaemon.
1 Like
ok everything is fine but i really don’t know how to install the package https://github.com/efficiosoft/hass-apps/archive/overlay-rework.zip
Is added in
"python_packages": [
"Hass-apps"
"Http://github.com/efficiosoft/hass-apps/archive/overlay-rework.zip"
]
in requirements.txt
hass-apps
https://github.com/efficiosoft/hass-apps/archive/overlay-rework.zip
no matter where I would add it does not install.
You must add only the URL, not both “hass-apps” and the URL. “hass-apps” points to the stable version from PyPi and your luck then depends on what ends up being installed last.
EDIT: And you don’t need requirements.txt when using hassio. All of this is described in the Getting started section in the docs.
ok i tried all the combinations so that’s the config. Now in config I have only your link. I attach the logo below, nothing has changed.