Heaty will die, Schedy be born!

@GAtti I assume you want to split up the configuration into one for each room. That’s not possible unless you create a separate Schedy instance per room, with all the drawbacks this has.

@haakeik You probably haven’t restarted HA after modifying customize.yaml, but without a proper debug log I can’t know.

Hmmm, weird.
I’ve tested Schedy from my remote office and used States in the development tool to put the door sensor in “on” mode. Then the “turn off thermostat” function does not work. If I really open the door, it works fine, every time.

Log from using States to set the sensor in “on” mode:

2019-08-23 16:06:23.631306 INFO hello_world: Hello from AppDaemon
2019-08-23 16:06:23.632090 INFO hello_world: You are now ready to run Apps!
2019-08-23 16:06:23.632596 INFO AppDaemon: App initialization complete
2019-08-23 16:07:50.587706 INFO schedy_heating: --> Attribute ‘state’ of ‘binary_sensor.door_window_sensor_158d0001a1eeda’ changed from ‘off’ to ‘on’, reevaluating .
2019-08-23 16:07:50.591097 INFO schedy_heating: — [R:gjesterom] Doing schedule re-evaluation in 1 second [reset=False]
2019-08-23 16:07:51.007774 INFO schedy_heating: — [R:gjesterom] Evaluating room’s schedule (reset=False, force_resend=False).
2019-08-23 16:07:51.010044 INFO schedy_heating: — [R:gjesterom] Assuming it to be 2019-08-23 16:07:51.
2019-08-23 16:07:51.013118 INFO schedy_heating: — [R:gjesterom] ������ [SUB] <<Schedule ‘gjesterom’>/1:<Rule with sub <Schedule ‘prepend’>>>
2019-08-23 16:07:51.016078 INFO schedy_heating: — [R:gjesterom] ������ [ACT] <<Schedule ‘gjesterom’>/1/1:<Rule x=‘Mark(OFF, Mark.OVERLAY) if not is_empty(’…>>
2019-08-23 16:07:51.018792 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: BasicHelper, order = 0
2019-08-23 16:07:51.021473 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: PatternHelper, order = 0
2019-08-23 16:07:51.023830 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: ScheduleHelper, order = 0
2019-08-23 16:07:51.026527 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: StateHelper, order = 0
2019-08-23 16:07:51.029691 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: ThermostatExpressionHelper, order = 0
2019-08-23 16:07:51.032401 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: CustomEnvironmentHelper, order = 1000
2019-08-23 16:07:51.036552 INFO schedy_heating: — [R:gjesterom] ������ => Skip()
2019-08-23 16:07:51.038280 INFO schedy_heating: — [R:gjesterom] ������ [SUB] <<Schedule ‘gjesterom’>/2:<Rule with sub <Schedule ‘room-individual’>>>
2019-08-23 16:07:51.039665 INFO schedy_heating: — [R:gjesterom] ������ [SUB] <<Schedule ‘gjesterom’>/2/1:<Rule with sub <Schedule of 2 rules>, v=20>>
2019-08-23 16:07:51.041099 INFO schedy_heating: — [R:gjesterom] ������ [SUB] <<Schedule ‘gjesterom’>/2/1/1:<Rule with sub <Schedule of 2 rules>, weekdays={1-5}>>
2019-08-23 16:07:51.042540 INFO schedy_heating: — [R:gjesterom] ������ [INA] <<Schedule ‘gjesterom’>/2/1/1/1:<Rule from 06:00 to 11:30>>
2019-08-23 16:07:51.043658 INFO schedy_heating: — [R:gjesterom] ������ [ACT] <<Schedule ‘gjesterom’>/2/1/1/2:<Rule from 15:00 to 19:00>>
2019-08-23 16:07:51.044692 INFO schedy_heating: — [R:gjesterom] ������ => 20
2019-08-23 16:07:51.045665 INFO schedy_heating: — [R:gjesterom] Final result: 20.0��
2019-08-23 16:07:51.046549 INFO schedy_heating: — [R:gjesterom] Result didn’t change, not setting it again.
2019-08-23 16:07:51.047557 INFO schedy_heating: — [R:gjesterom] Unchanged HA state: state=‘20.0’, attributes={‘actor_wanted_values’: {‘climate.thermofloor_as_heatit_thermostat_tf_021_heating_3’: ‘20.0’}, ‘scheduled_value’: ‘20.0’, ‘rescheduling_time’: None, ‘overlay_revert_on_no_result’: False}

Log from open the door:

2019-08-23 16:11:34.435384 INFO schedy_heating: --> Attribute ‘state’ of ‘binary_sensor.door_window_sensor_158d0001a1eeda’ changed from ‘off’ to ‘on’, reevaluating .
2019-08-23 16:11:34.438442 INFO schedy_heating: — [R:gjesterom] Doing schedule re-evaluation in 1 second [reset=False]
2019-08-23 16:11:35.004848 INFO schedy_heating: — [R:gjesterom] Evaluating room’s schedule (reset=False, force_resend=False).
2019-08-23 16:11:35.007069 INFO schedy_heating: — [R:gjesterom] Assuming it to be 2019-08-23 16:11:35.
2019-08-23 16:11:35.009119 INFO schedy_heating: — [R:gjesterom] ������ [SUB] <<Schedule ‘gjesterom’>/1:<Rule with sub <Schedule ‘prepend’>>>
2019-08-23 16:11:35.011206 INFO schedy_heating: — [R:gjesterom] ������ [ACT] <<Schedule ‘gjesterom’>/1/1:<Rule x=‘Mark(OFF, Mark.OVERLAY) if not is_empty(’…>>
2019-08-23 16:11:35.013376 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: BasicHelper, order = 0
2019-08-23 16:11:35.015681 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: PatternHelper, order = 0
2019-08-23 16:11:35.017657 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: ScheduleHelper, order = 0
2019-08-23 16:11:35.019668 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: StateHelper, order = 0
2019-08-23 16:11:35.021867 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: ThermostatExpressionHelper, order = 0
2019-08-23 16:11:35.024720 INFO schedy_heating: — [R:gjesterom] Initializing expression helper: CustomEnvironmentHelper, order = 1000
2019-08-23 16:11:35.028164 INFO schedy_heating: — [R:gjesterom] ������ => Mark(OFF, {‘OVERLAY’})
2019-08-23 16:11:35.029469 INFO schedy_heating: — [R:gjesterom] Final result: OFF
2019-08-23 16:11:35.030694 INFO schedy_heating: — [R:gjesterom] Result markers: {‘OVERLAY’}
2019-08-23 16:11:35.031952 INFO schedy_heating: — [R:gjesterom] Setting value to OFF. [scheduled]
2019-08-23 16:11:35.033193 INFO schedy_heating: <-- [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Setting value OFF (left tries = 9).
2019-08-23 16:11:35.034458 INFO schedy_heating: <-- [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Setting temperature = ‘’, HVAC mode = ‘off’.
2019-08-23 16:11:35.048244 INFO schedy_heating: — [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Re-sending in 30 seconds.
2019-08-23 16:11:35.049362 INFO schedy_heating: <-- [R:gjesterom] Value set to OFF. [scheduled]
2019-08-23 16:11:35.050468 INFO schedy_heating: <-- [R:gjesterom] Sending state to HA: state=‘OFF’, attributes={‘actor_wanted_values’: {‘climate.thermofloor_as_heatit_thermostat_tf_021_heating_3’: ‘OFF’}, ‘scheduled_value’: ‘OFF’, ‘rescheduling_time’: None, ‘overlay_revert_on_no_result’: False}
2019-08-23 16:11:35.250858 INFO schedy_heating: --> [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Attribute ‘state’ is ‘off’.
2019-08-23 16:11:35.253422 INFO schedy_heating: --> [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Attribute ‘current_temperature’ is 21.0.
2019-08-23 16:11:35.256049 INFO schedy_heating: — [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Cancelled re-sending timer.
2019-08-23 16:11:35.264828 INFO schedy_heating: --> [R:gjesterom] [A:climate.thermofloor_as_heatit_thermostat_tf_021_heating_3] Received value of OFF.
2019-08-23 16:11:35.265880 INFO schedy_heating: — [R:gjesterom] Unchanged HA state: state=‘OFF’, attributes={‘actor_wanted_values’: {‘climate.thermofloor_as_heatit_thermostat_tf_021_heating_3’: ‘OFF’}, ‘scheduled_value’: ‘OFF’, ‘rescheduling_time’: None, ‘overlay_revert_on_no_result’: False}

@haakeik Great that it’s working now.

thats because HA doesnt generate an event when you set the state through the development tool.
and without that event it cant be picked up by appdaemon (schedy)

Hi @roschi.

When playing with schedules I got one idea which I do not see a way how to achieve. But I think it can be a lot usefull.

To introduce some delay in action. Eg. wait 10 second until the schedule is evaluated once triggered (configurable of course).

And why? Imagine following model situation.
You have a flat , several room, all equiped with thermostats (TRVs) and window sensors. One of the window sensors is covering the door to the balcony. And in the winter you simply need to put something there to cool down or pick up a thing. That means to open door for few seconds. Which of course triggers the TRV to turn fully OFF and then back to ON and proper temperature target.

So having some protective interval can a lot help with lifetime of batteries to not toggle the TRVs for nothing.

Just something to think of :wink:

I have a dumb questipn. What can i do if my climate has no attribute temperature BUT current_temperature? How can I use shedy then? With all the reword of the climate it seems broken

@thundergreen current_temperature is the temperature as measured by the thermostat’s temperature sensor while temperature is the set target temperature. There’s something wrong with the HA integration for your thermostat if it has no temperature.

@TriStone I’ll think about it and let you know.

OK…got it thanks.seems like it’s working. But I’ll have to rewrite my entire configuration. Need to use heat and cool.

Hi @TriStone
I did this with a binary template sensor that requires the door to be open for > 1 minute before it get set. This works fine for almost a year now.

This is my sensor

  - platform: template
    sensors:
      dol_door_open_long:
        friendly_name: "Dolfijnen deur lang open"
        delay_on: 
          minutes: 1  # Wait 1 minute before switching off the heat
        delay_off:
          minutes: 1  # Wait 1 minute before switching on the heat for shooking doors
        value_template: >-
          {{ is_state('binary_sensor.dolfijnen_deur', 'on') }}

        icon_template: >-
          {% if is_state('binary_sensor.dolfijnen_deur', 'on') %}
            mdi:door-open
          {% else %}
            mdi:door-closed
          {% endif %}
2 Likes

@taste and @TriStone Yes, currently, this is the easiest solution I guess. Native support would require recording and querying state history, since just delaying the reevaluation would not be enough if e.g. another state change triggers a reevaluation in between.

Thanks @taste for the proposal. I was not aware of the delay in template sensor, my bad :slight_smile:

@roschi I think this is not just easier, this is even better solution :slight_smile: Cause it affects just the window behavior and not whole schedule :+1:

Sure, I was thinking about supporting delayed state change recognition for specific entities in Schedy directly, but the effort and amount of complexity is probably not worth it.

Hi together!
I initially configured Schedy for the last heating period 2018/2019. This worked wonderful.
Setup is following:
MAX! Thermostats —> CUN—>Homegear --> MQTT --> HASS.IO

I didn’t pay attention to it until now but I noticed 2 things:
1)
My AppDaemon Log ist filled with these messages:

2019-09-02 19:10:36.028164 WARNING schedy_heating: !!! [R:Kueche] [A:climate.kueche_thermostat] Re-sending value due to missing feedback.
2019-09-02 19:11:06.002349 WARNING schedy_heating: !!! [R:Kueche] [A:climate.kueche_wandthermostat] Re-sending value due to missing feedback.
2019-09-02 19:11:06.025767 WARNING schedy_heating: !!! [R:Kueche] [A:climate.kueche_thermostat] Re-sending value due to missing feedback.

This is a new behavior for me. Due to this behavior, the airtime of the devices for radio transmission is used up very quickly.
I tried to stop this by customizing the custom actor as follows:

    default:
      supports_hvac_modes: false
      off_temp: 4.5
      send_retries: 0

But in the Logs I can see still the retries.

Where does Schedy got the Feedback for the Value for? Is this a new behavior?

The second thing i noticed is a Problem with the off_temp. I have the following schedule_prepend:

schedule_prepend:
   - x: "OFF if is_on('input_boolean.heizung_sommer') else Skip()"
   - x: "19 if is_off('binary_sensor.zuhause') else Skip()"
   - x: "Mark(OFF, Mark.OVERLAY) if not is_empty(filter_entities('binary_sensor', window_room=room_name, state='on')) else Skip()"

But instead of sending the 4.5 to the thermostat it sends 5.0.


2019-09-02 19:19:34.816787 INFO schedy_heating: --> Attribute 'state' of 'input_boolean.heizung_sommer' changed from 'off' to 'on', reevaluating 4 rooms.
2019-09-02 19:19:35.164865 INFO schedy_heating: <-- [R:Arbeitszimmer] Value set to OFF.  [scheduled]
2019-09-02 19:19:35.218126 INFO schedy_heating: <-- [R:Schlafzimmer] Value set to OFF.  [scheduled]
2019-09-02 19:19:35.229445 INFO schedy_heating: <-- [R:Wohnzimmer] Value set to OFF.  [scheduled]
2019-09-02 19:19:36.278544 INFO schedy_heating: --> [R:Arbeitszimmer] [A:climate.arbeitszimmer_wandthermostat] Received value of 5.0��.
2019-09-02 19:19:37.386902 INFO schedy_heating: --> [R:Arbeitszimmer] [A:climate.arbeitszimmer_thermostat] Received value of 5.0��.
2019-09-02 19:19:39.599465 INFO schedy_heating: --> [R:Schlafzimmer] [A:climate.schlafzimmer_wandthermostat] Received value of 5.0��.
2019-09-02 19:19:40.705934 INFO schedy_heating: --> [R:Schlafzimmer] [A:climate.schlafzimmer_thermostat] Received value of 5.0��.

I have no Idea why…

Maybe somebody can Help?

Hi,

Without proper debug logs, no chance.

Maybe your thermostat simply doesn’t support temperatures below 5°C? Can you manually set 4.5 from the HA UI? When Schedy sends 4.5 but receives 5.0 as feedback, it of course resends the value because the thermostat didn’t react as expected.

BTW, send_retries: 0 was broken, which is fixed in the development version, in case you want to try it out.

Hi,
thanks for your reply!

4.5 is the temperature where the thermostats go into the state “off” and close the valve complete.

I checked the communication a little more. In the HA UI i can select 4.5 ( i set it as minimum temperature ) and it sit’s there a while and jumps back to 5. I checked the transmitted data via wirless and can see, that the transmitted value is 5… So Schedy is not the Problem, there must be something else changed between last winter and now…

Maybe i can get behind this and see what happend. If not, i will set the Off temp in Schedy to 5… Quick and Dirty. :smiley:

Actually, as long as temperature is above 5°C, the walves should as well be closed when 5.0° is set, shouldn’t they?

Hey
I have a problem with the operation of the thermostatic heads (Eurotronic Spiritz TRV Z-Wave) in Schedy. namely, I have a room and two thermostatic heads + a window sensor.
Configuration below.

schedy_heating.yaml:

schedy_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) 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_2:
            max_temp: 24
        climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3:
            max_temp: 24
      watched_entities:
      - binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor

customize.yaml:

  binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor:
  window_room: living

Immediately after turning on the HA and opening the window, the thermostats are off and this is how it should be, I close the window, the thermostats do not return to the state they had before opening.
This is the first thing I wanted to ask about.

Another one… passes a few minutes again
I open the window in the log it is registered but the thermostats remain unchanged, I manually set the terperature on the thermostat and then after a while they go into the off state.

below I attach log

2019-09-06 11:06:24.328307 INFO AppDaemon: HASS: Connected to Home Assistant 0.98.4
2019-09-06 11:06:24.341872 WARNING AppDaemon: HASS: Disconnected from Home Assistant, retrying in 5 seconds
2019-09-06 11:06:29.363767 INFO AppDaemon: HASS: Connected to Home Assistant 0.98.4
2019-09-06 11:06:30.118410 INFO AppDaemon: Processing restart for HASS
2019-09-06 11:06:30.120829 INFO AppDaemon: Terminating schedy_heating
2019-09-06 11:06:30.121915 INFO AppDaemon: Terminating hello_world
2019-09-06 11:06:30.123086 INFO AppDaemon: Initializing app schedy_heating using class SchedyApp from module hass_apps_loader
2019-09-06 11:06:30.131959 INFO schedy_heating: *** Welcome to schedy 0.5.0, running on AppDaemon 3.0.5.
2019-09-06 11:06:30.139253 INFO schedy_heating: *** 
2019-09-06 11:06:30.146461 INFO schedy_heating: *** This is an app from the hass-apps package.
2019-09-06 11:06:30.154064 INFO schedy_heating: ***   DOCS: https://hass-apps.readthedocs.io/en/stable/
2019-09-06 11:06:30.159919 INFO schedy_heating: *** 
2019-09-06 11:06:30.165742 INFO schedy_heating: *** You like this app, want to honor the effort put into
2019-09-06 11:06:30.171100 INFO schedy_heating: *** it, ensure continuous development and support?
2019-09-06 11:06:30.177457 INFO schedy_heating: *** Then please consider making a donation.
2019-09-06 11:06:30.188949 INFO schedy_heating: ***   DONATE: https://hass-apps.readthedocs.io/en/stable/#donations
2019-09-06 11:06:30.196750 INFO schedy_heating: *** Thank you very much and enjoy schedy!
2019-09-06 11:06:30.203919 INFO schedy_heating: *** 
2019-09-06 11:06:30.232123 INFO schedy_heating: --- Actor type is: 'thermostat'
2019-09-06 11:06:30.314344 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2] Received value of 23.0��.
2019-09-06 11:06:30.391707 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3] Received value of 23.0��.
2019-09-06 11:06:30.558786 WARNING AppDaemon: schedy_heating: Entity schedy_room.schedy_heating_living not found in AppDaemon
2019-09-06 11:06:30.705423 INFO schedy_heating: *** Initialization done.
2019-09-06 11:06:30.706154 INFO AppDaemon: Initializing app hello_world using class HelloWorld from module hello
2019-09-06 11:06:30.713393 INFO hello_world: Hello from AppDaemon
2019-09-06 11:06:30.718640 INFO hello_world: You are now ready to run Apps!
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.
2019-09-06 11:07:50.703807 INFO schedy_heating: --> Attribute 'state' of 'binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor' changed from 'on' to 'off', reevaluating <Room R:living>.
2019-09-06 11:10:32.970319 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_2] Received value of 23.0��.
2019-09-06 11:10:32.982990 INFO schedy_heating: --- [R:living] Propagating the change to all actors in the room.
2019-09-06 11:10:33.124634 INFO schedy_heating: <-- [R:living] Value set to 23.0��.  [manual]
2019-09-06 11:10:33.130461 INFO schedy_heating: --- [R:living] Re-applying the schedule not before 11:11:33 (in 0:01:00).
2019-09-06 11:10:34.661847 INFO schedy_heating: --> [R:living] [A:climate.eurotronic_eur_spiritz_wall_radiator_thermostat_heat_3] Received value of 23.0��.
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.
2019-09-06 11:24:13.808684 INFO schedy_heating: --> Attribute 'state' of 'binary_sensor.shenzhen_neo_electronics_co_ltd_door_window_detector_sensor' changed from 'on' to 'off', reevaluating <Room R:living>.

please help :slight_smile:

These thermostats have a built-in open window detection that turns them off when a sudden temperature rush is detected. You should turn it off and then see if you can still observe something unexpected.