Heaty will die, Schedy be born!

[SaxnPaule]

Hello community,

until yesterday my home assistant installation worked well. Unfortunately the system crashed. Now everything is working again except schedy heating.

I have the default rule for window open recognition.

  schedule_prepend:
  - x: "Mark(5, Mark.OVERLAY) if not is_empty(filter_entities('binary_sensor', window_room=room_name, state='on')) else Next()"

Everytime a window is opened, appdeamon throws an error, because in home assitant an error is thrown and the API answers with a 500.

Also if I add the window contact explicit to one room and deactivate the global rule, the same error is thrown.

- x: "5 if is_on('binary_sensor.aqara_window_2_schlafzimmer') else Next()"

My setup is a docker environment where each component is an own docker container.

Thats the error:

homeassistant    | 2019-12-27 17:51:12 ERROR (MainThread) [aiohttp.server] Error handling request
homeassistant    | Traceback (most recent call last):
homeassistant    |   File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
homeassistant    |     resp = await task
homeassistant    |   File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
homeassistant    |     resp = await handler(request)
homeassistant    |   File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
homeassistant    |     return await handler(request)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/http/real_ip.py", line 40, in real_ip_middleware
homeassistant    |     return await handler(request)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 73, in ban_middleware
homeassistant    |     return await handler(request)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 136, in auth_middleware
homeassistant    |     return await handler(request)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 122, in handle
homeassistant    |     result = await result
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/api/__init__.py", line 355, in post
homeassistant    |     domain, service, data, True, self.context(request)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/core.py", line 1236, in async_call
homeassistant    |     await asyncio.shield(self._execute_service(handler, service_call))
homeassistant    |   File "/usr/src/homeassistant/homeassistant/core.py", line 1261, in _execute_service
homeassistant    |     await handler.func(service_call)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
homeassistant    |     self._platforms.values(), func, call, service_name, required_features
homeassistant    |   File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 348, in entity_service_call
homeassistant    |     future.result()  # pop exception if have
homeassistant    |   File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 372, in _handle_service_platform_call
homeassistant    |     await func(entity, data)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 529, in async_service_temperature_set
homeassistant    |     await entity.async_set_temperature(**kwargs)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 390, in async_set_temperature
homeassistant    |     ft.partial(self.set_temperature, **kwargs)
homeassistant    |   File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
homeassistant    |     result = self.fn(*self.args, **self.kwargs)
homeassistant    |   File "/usr/src/homeassistant/homeassistant/components/maxcube/climate.py", line 124, in set_temperature
homeassistant    |     cube.set_target_temperature(device, target_temperature)
homeassistant    |   File "/usr/local/lib/python3.7/site-packages/maxcube/cube.py", line 246, in set_target_temperature
homeassistant    |     self.set_temperature_mode(thermostat, temperature, thermostat.mode)
homeassistant    |   File "/usr/local/lib/python3.7/site-packages/maxcube/cube.py", line 270, in set_temperature_mode
homeassistant    |     command = 's:' + base64.b64encode(bytearray.fromhex(byte_cmd)).decode('utf-8') + '\r\n'
homeassistant    | ValueError: non-hexadecimal number found in fromhex() arg at position 21
appdaemon_1      | 2019-12-27 18:51:12.019854 WARNING AppDaemon: ------------------------------------------------------------
appdaemon_1      | 2019-12-27 18:51:12.019970 WARNING AppDaemon: Unexpected error in worker for App schedy_heating:
appdaemon_1      | 2019-12-27 18:51:12.020069 WARNING AppDaemon: Worker Ags: {'name': 'schedy_heating', 'id': UUID('503fb818-0c88-485a-a05f-xxxxxxxxxx'), 'type': 'timer', 'function': <function Room.trigger_reevaluation.<locals>._reevaluation_cb at 0x7fdbac1668c8>, 'kwargs': {}}
appdaemon_1      | 2019-12-27 18:51:12.020141 WARNING AppDaemon: ------------------------------------------------------------
appdaemon_1      | 2019-12-27 18:51:12.020431 WARNING AppDaemon: Traceback (most recent call last):
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 586, in worker
appdaemon_1      |     funcref(self.sanitize_timer_kwargs(app, args["kwargs"]))
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/room.py", line 723, in _reevaluation_cb
appdaemon_1      |     self.apply_schedule(reset=reset)
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/room.py", line 50, in wrapper
appdaemon_1      |     result = handler(self, *args, **kwargs)
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/room.py", line 409, in apply_schedule
appdaemon_1      |     self.set_value(new_scheduled_value, force_resend=force_resend)
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/room.py", line 587, in set_value
appdaemon_1      |     changed |= actor.set_value(value, force_resend=force_resend)[0]
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/actor/base.py", line 285, in set_value
appdaemon_1      |     self._resending_cb({"left_tries": self.cfg["send_retries"] + 1})
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/room.py", line 50, in wrapper
appdaemon_1      |     result = handler(self, *args, **kwargs)
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/actor/base.py", line 93, in _resending_cb
appdaemon_1      |     self.do_send()
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/hass_apps/schedy/actor/thermostat.py", line 326, in do_send
appdaemon_1      |     temperature=temp.value,
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/appdaemon/plugins/hass/hassapi.py", line 22, in func_wrapper
appdaemon_1      |     return func(*args, **kwargs)
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/appdaemon/plugins/hass/hassapi.py", line 522, in call_service
appdaemon_1      |     r.raise_for_status()
appdaemon_1      |   File "/usr/local/lib/python3.6/site-packages/requests/models.py", line 940, in raise_for_status
appdaemon_1      |     raise HTTPError(http_error_msg, response=self)
appdaemon_1      | requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http://192.168.0.7:8123/api/services/climate/set_temperature

The room and the contact/thermostat doesn’t matter. Error occurs in all rooms.

On window close, the corresponding rules are revalidated and everything works fine.

What could be wrong?

[roschi]

Hi @SaxnPaule

This almost certainly is an issue with the maxcube component and not related to Schedy. Try setting the temperature to 5° manually from HA UI and check if the same error is produced. If so, open an issue against HA on GitHub.

[SaxnPaule]

Setting values via the UI works without any problems. 5°, 10°, 20° everything is possible. The normal heating plan via schedy also works. Only when executing the “window open” rule the error is thrown and no temperature is applied.

EDIT: I installed everything from scratch. Behavior is still the same

[roschi]

Try this:

1. Make sure the regular schedule is applied, e.g. the state before you’d open a window.
2. Call the climate.set_temperature service from HA dev tools with the appropriate entity and this service data: {"temperature": 5.0}

Does the error occur? It should, because this is exactly what Schedy does.

[SaxnPaule]

Yes, you’re right. The error occurs.

EDIT: It works for all values >= 8.0°C
Default OFF mode is 4.5°C. Well, I’ll use it with 8.0°C as workaround.

[roschi]

@SaxnPaule Ok, so it surely is an issue with the maxcube integration. But then it’s important that you file an issue so that it can be fixed.

[breti (Jens Bretschneider)]

Thanks again for your great support on Christmas Eve! Schedy is working like a charm now.

I’ve filed an issue with home assistant regarding the homematic integration / HM-CC-TC HVAC mode support: https://github.com/home-assistant/home-assistant/issues/30251

[matthewjporter (Mr P)]

Hi All. Looking some advise or examples

I have schedy working perfect to control my heating in various rooms with an input.select to determine if i home or away to switch around schedules

I am struggling to get presence detection working for multipe people and is where I need some assistance

My situation is that my son and his girlfriend have moved home and since they work odd shifts I am trying to create a schedule based on one or both of their location changing from/to either home/work/away

I use life 360 so know when they are at home/work/away or leave a location etc

I dont seem to be able to do or understand how I could get the schedule to change based on one or both being at work or leaving home - individually is simple, but combined I am not sure how to do this

Does it make sense what I am trying to do and any help/pointers would be greatfull

Matthew

[roschi]

Hi @matthewjporter

Sounds like what you want is to use a simple or in the expression that checks for presence state. If you can do it for a single person, you can have the if-expression evaluate to true if at least one of multiple persons is at home as well.

- x: "... if state('son') == 'home' or state('girlfriend') == 'home' else ..."

[breti (Jens Bretschneider)]

Sorry, another question: If rescheduling_delay is not set anywhere, when does Schedy return to the schedule after a manual temperature change at the thermostat?

[Mr_Q]

Hi,

Thank you very much for Schedy! This is really a nice solution which saved me a lot of time creating an automation within HA to get the schedules done. I’m using it to control all the radiators in my room using the evohome integration of HomeAssistant.

I also have two airco-units which are controlled by two ‘ambi climate 2’ which also integrate with Home Assistant. These devices are cloud controlled and have some kind of A.I. to reach a specific target temperature. This means it can set the airco to ‘heat’ / 30 degrees for a couple of minutes even though the target temperature was only 21 degrees. What I’m trying to say is that it’s not just a simple infrared/signal forwarder, which makes it a bit harder to integrate it with Schedy for two reasons:

• ‘temperature mode’ has a separate service (ambiclimate.set_temperature_mode) to configure the temperature.
• in the current ambiclimate integration there’s no value to monitor for the temperature-mode setting. Yes there’s ‘temperature’ and ‘current_temperature’ but it only refers to what is sent to the airconditioing and real temperature measured, but not the target temperature set within the temperature-mode.

This means I have created a generic-actor and the second attribute is set to ‘null’ to make it write-only and not have schedy validate the value (as it simply can’t). If I finished my main automations/integrations I might look into the code of the ambiclimate integration to get it available, but for now there’s no way…

So the actual issue I have is that I have to specific data to the service, which depends on the room what the information should be. However, this can not be set on room-level so I can not combine both rooms I have (‘woonkamer’ and ‘slaapkamer’) into one schedy.

Here’s the yaml file of ‘woonkamer’, it is nearly the same for ‘slaapkamer’ except for the service-data and of course the room name/input_select.

schedy_ac_woonkamer:
  module: hass_apps_loader
  class: SchedyApp
  expression_modules:
    math:
  actor_type: generic
  # call_reversed: true
  actor_templates:
    default:
      attributes:
      - attribute: state
        values:
          'off':
            service: "climate.turn_off"
          'heat':
            service: "climate.turn_on"
      - attribute: null
        values:
          '_other_':
            # service: "climate.set_temperature"
            service: "ambiclimate.set_temperature_mode"
            service_data: { name: 'AC Woonkamer' }
            include_entity_id: false
            value_parameter: 'value'
      short_values:
      - ["off"]
      - ["on", "_other_"]
      send_retries: 0
      send_retry_interval: 10
      # call_reversed: true

  rooms:
    woonkamer:
      # friendly_name: AC Woonkamer
      actors:
        climate.ac_woonkamer:
      schedule:
      # - x: "Break() if state('input_select.heatmode_woonkamer') != 'AC' else Next()"
      - x: "['heat', 21]"
        # - x: "['off']"
      watched_entities:
      - input_select.heatmode_woonkamer
      
  schedule_prepend:
  - name: Global schedule on/off switch AC
    x: "Abort() if is_off('input_boolean.schedy_ac') else Next()"
  - name: Per room decide to use AC or not
    x: "'off' if state('input_select.heatmode_' + room_name) != 'AC' else Next()"

  watched_entities:
  - input_boolean.schedy_ac

It would be great if there’s a way to provide service_data based on the room, as this allows me to combine both room within one ‘app’ instead of creating two nearly identical onces. Any ideas? Otherwise I’ll keep it as it is. It does work this way but requires more maintenance/attention.

Either way; thank you very much for the great and continuous support provided, I’m really happy with it.

[roschi]

Sorry, another question: If rescheduling_delay is not set anywhere, when does Schedy return to the schedule after a manual temperature change at the thermostat?

No problem

It then returns to schedule the next time the scheduled value changes.

[roschi]

Hi @Mr_Q

That’s an interesting application for the generic actor type, thanks for sharing!

The only thing you could do is to stop using the default actor template and instead create two ones, one for each room and then set the correct template for each actor. That way you have everything inside one Schedy instance.

There will be a new generic2 actor type at some point (I know, I said it would be finished earlier, but I didn’t find the time yet), which will make the selection of services to call more dynamic and will allow you to specify just the temperature, without "heat" infront of. So stay tuned.

BTW, whereever you got this sample config from, expression_modules is no longer supported and has been superseeded by expression_environment.

[Mr_Q]

Thank you for the quick reply.

The idea of a different template is a good idea! I changed it and now I can work with a single instance. I also used some default values although I noticed that the default values were only picked up when I added ‘template: default’ to the other templates; I thought I read this wasn’t required but anyway, now it works! I also noticed that I can not put the common attributes (first one in my case for on/off of the device), which is works as designed I guess.

In regards to the generic2-actor, I’m looking forward to it, who knows it can help me out in some of the automation cases.

I did notice an ‘issue’ with the rescheduling_delay. I was just playing it and I don’t think I would like to use it (as I can’t read the actual target temperature set at the ambi-climate device) but I did expect it to work for ‘on’ and ‘off’ which are readable by the state of the climate-device.

Here’s the log:

2019-12-30 14:47:18.539865 INFO schedy_ac: *** Initialization done.
2019-12-30 14:47:18.540437 WARNING AppDaemon: Excessive time spent in utility loop: 6966.0ms
2019-12-30 14:47:25.001905 WARNING schedy_ac: !!! [R:AC Woonkamer] [A:climate.ac_woonkamer] Re-sending value due to missing confirmation.
2019-12-30 14:47:28.001988 WARNING schedy_ac: !!! [R:AC Slaapkamer] [A:climate.ac_slaapkamer] Re-sending value due to missing confirmation.
2019-12-30 14:47:39.003281 WARNING schedy_ac: !!! [R:AC Woonkamer] [A:climate.ac_woonkamer] Gave up sending value after 1 retries.
2019-12-30 14:47:42.003134 WARNING schedy_ac: !!! [R:AC Slaapkamer] [A:climate.ac_slaapkamer] Gave up sending value after 1 retries.
2019-12-30 14:49:06.539655 INFO schedy_ac: --> [R:AC Woonkamer] [A:climate.ac_woonkamer] Received value of 'off'.
2019-12-30 14:52:10.714418 INFO schedy_heating: --> [R:badkamer] [A:climate.badkamer] Received value of 18.0��.
2019-12-30 14:52:10.716320 INFO schedy_heating: --- [R:badkamer] Re-applying the schedule not before 15:52:10 (in 1:00:00).

Based on my configuration (below), I would expect that the ‘schedy_ac’ instance would turn back on the device because of the ‘rescheduling_delay’ being set to 1 for the ‘AC Woonkamer’ room. The schedy_heating which is also in the log, is a different instance which I use for my evohome, but it was to show you that it does work for that instance. Of course, that is a different actor (thermostat).

to reply to your question regarding ‘expression_modules’. I found it something on github which looked like a good base to me, but because of your comment, I have recreated my config based on the latest configuration file of the logs. Here it is:

schedy_ac:
  module: hass_apps_loader
  class: SchedyApp

  # Enable debugging output
  #debug: true

  # restore previous state or reset at startup
  reset_at_startup: true

  # make expressions more safe
  #expressions_from_events: false

  # expressions environment stuff
  #expression_environment: |
  #  import math
  #  import time as _time
  #  something = "value"

  actor_type: generic
  actor_templates:
    # By default, an actor inherits its settings from the "default" template.
    # removed default template
    default:
      send_retries: 1
      send_retry_interval: 10
      # call_reversed: true

    woonkamer:
      template: default
      attributes:
      - attribute: state
        values:
          'off':
            service: "climate.turn_off"
          'heat':
            service: "climate.turn_on"
      - attribute: null
        values:
          '_other_':
            service: "ambiclimate.set_temperature_mode"
            service_data: { name: 'AC Woonkamer' }
            include_entity_id: false
            value_parameter: 'value'
      short_values:
      - ["off"]
      - ["on", "_other_"]

    slaapkamer:
      template: default
      attributes:
      - attribute: state
        values:
          'off':
            service: "climate.turn_off"
          'heat':
            service: "climate.turn_on"
      - attribute: null
        values:
          '_other_':
            service: "ambiclimate.set_temperature_mode"
            service_data: { name: 'AC Slaapkamer' }
            include_entity_id: false
            value_parameter: 'value'
      short_values:
      - ["off"]
      - ["on", "_other_"]


  schedule_prepend:
  - name: Global schedule on/off switch AC
    x: "Abort() if is_off('input_boolean.schedy_ac') else Next()"
  - name: Per room decide to use AC or not
    x: "'off' if state('input_select.heatmode_' + room_name) != 'AC' else Next()"
  - name: Disable AC when window of room is open
    x: "'off' if not is_empty(filter_entities('binary_sensor', state='on', window_room=room_name)) else Next()"

  schedule_append:

  schedule_snippets:

  watched_entities:
  - input_boolean.schedy_ac
  
  rooms:
    woonkamer:
      friendly_name: AC Woonkamer
      #allow_manual_changes: true
      # 0 means not re-schedule before the next scheduled value change
      rescheduling_delay: 1 # only for testing set to 1!
      actors:
        climate.ac_woonkamer:
          template: woonkamer
      schedule:
      - x: "['heat', 21]"
      # - x: "['off']"

      watched_entities:
      - input_select.heatmode_woonkamer

    slaapkamer:
      friendly_name: AC Slaapkamer
      #allow_manual_changes: true
      # 0 means not re-schedule before the next scheduled value change
      #rescheduling_delay: 0
      actors:
        climate.ac_slaapkamer:
          template: slaapkamer
      schedule:
      - x: "['heat', 18]"
      # - x: "['off']"

      watched_entities:
      - input_select.heatmode_slaapkamer
      - binary_sensor.door_sensor_654_raam_slaapkamer_contact

If I didn’t say it before, the documentation you provide is really outstanding (compared to many others!) and helped me out to get this up and running quickly, thank you for that! I’m going to look into the ‘events’ shortly, didn’t really look into that yet.

Oh yea, one more question, when I look at the developer tools / states of entities, I see a lot of statisics-related entities with the name ‘schedy’ in it. In none of my configuration files I use ‘statistics’ at the moment so I do wonder how these entities were added. I guess I know how they got in, but I’m not sure how to get them out. Example:
‘schedy_room.schedy_ac_living’

Pretty sure it is because I use the webbased Visual Studio Code which directly saves the file (and in case of AppDaemon re-reads/starts the instance) and I copied the example configuration in it, which directly got activated. The thing is that the room ‘living’ is gone from the configuration but I can still see it in the list of entities. Same counts for some other typo’s I made (eg roomname_roomname) during the configuration build-up. Any idea how to clean these up?

Sorry for the long post…

[roschi]

The idea of a different template is a good idea! I changed it and now I can work with a single instance. I also used some default values although I noticed that the default values were only picked up when I added ‘template: default’ to the other templates; I thought I read this wasn’t required but anyway, now it works!

Actually this is intended behavior. An actor template inherits from no other template by default, only the final actors inherit from the default template if no other one is specified.

I also noticed that I can not put the common attributes (first one in my case for on/off of the device), which is works as designed I guess.

Correct, the template merging only works for dictionaries (mappings), not for lists, as this would result in ambiguities in the order of list items.

I did notice an ‘issue’ with the rescheduling_delay. I was just playing it and I don’t think I would like to use it (as I can’t read the actual target temperature set at the ambi-climate device) but I did expect it to work for ‘on’ and ‘off’ which are readable by the state of the climate-device.

Would you please open an issue on GitHub so that I can better track this? I’ll definitely investigate it then.

If I didn’t say it before, the documentation you provide is really outstanding (compared to many others!) and helped me out to get this up and running quickly, thank you for that! I’m going to look into the ‘events’ shortly, didn’t really look into that yet.

Thanks, this really means a lot to me! Designing and writing the documentation is at least as involved as programming Schedy itself (and at least as difficult to get right).

Oh yea, one more question, when I look at the developer tools / states of entities, I see a lot of statisics-related entities with the name ‘schedy’ in it. In none of my configuration files I use ‘statistics’ at the moment so I do wonder how these entities were added. I guess I know how they got in, but I’m not sure how to get them out.

The schedy_room entities are used to store current state of the individual rooms across Schedy restarts. However they should disappear when you restart HA, at least they are then no longer included in the states store.

[SaxnPaule]

Hello community,
I have a strange behavior of my schedy heating.
In my living room I have 3 thermostats with the following config:

living:

      friendly_name: Wohnzimmer
      
      allow_manual_changes: false
      
      replicate_changes: false

      rescheduling_delay: 0

      # All actors of this room go here.
      actors:

        climate.wohnzimmer_thermostat_1:
          template: default
          delta: 0
          off_temp: 8.0
          supports_hvac_modes: false
          
        climate.wohnzimmer_2_thermostat_2:
          template: default
          delta: 1
          off_temp: 8.0
          supports_hvac_modes: false
          
        climate.wohnzimmer_3_thermostat_3:
          template: default
          delta: 0
          off_temp: 8.0
          supports_hvac_modes: false

      # The room's schedule, consisting of multiple rules.
      schedule:
      - x: "21 if is_on('input_boolean.holiday_mode') else Next()"
      - v: 21
        months: 1-12
        weekdays: 5-7
        start: "07:00"
        end: "22:00"
      - months: 1-12
        weekdays: 1-4
        rules:
        - { v: 21, start: "06:30", end: "08:29" }
        - { v: 18, start: "08:30", end: "15:59" }
        - { v: 21, start: "16:00", end: "22:29" }
        - { v: 18, start: "22:30", end: "06:29" }
      
      # The same as the global watched_entities above, but these only
      #  trigger a re-evaluation for this particular room.
      watched_entities:
      - binary_sensor.aqara_window_3_balkon
      - input_boolean.holiday_mode

One of three works as expected but the other both are really strange. They jump between 18 and 21° all the time:

Working one:

Faulty one:

Whats going on there?

Log file snippet:

15:49:53: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'temperature' is 18.0.
15:49:53: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'current_temperature' is 22.6.
15:49:53: --- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Cancelled re-sending timer.
15:49:53: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Received value of 18.0��.
15:49:53: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:49:53: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:51:37: --- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Not sending value 18.0�� redundantly.
15:51:43: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:51:43: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'temperature' is 21.0.
15:51:43: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'current_temperature' is 22.6.
15:51:43: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Received value of 21.0��.
15:51:43: --- [R:Wohnzimmer] Rejecting manual value change by A:climate.wohnzimmer_thermostat_1 to 21.0��.
15:51:43: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting value 18.0�� (left tries = 11, interval = 30).
15:51:43: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting temperature = 18.0��, HVAC mode = '<unset>'.
15:51:55: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:51:55: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:51:55: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'temperature' is 18.0.
15:51:55: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'current_temperature' is 22.6.
15:51:55: --- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Cancelled re-sending timer.
15:51:55: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Received value of 18.0��.
15:51:55: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:53:39: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'temperature' is 21.0.
15:53:39: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Attribute 'current_temperature' is 22.6.
15:53:39: --> [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Received value of 21.0��.
15:53:39: --- [R:Wohnzimmer] Rejecting manual value change by A:climate.wohnzimmer_thermostat_1 to 21.0��.
15:53:39: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting value 18.0�� (left tries = 11, interval = 30).
15:53:39: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting temperature = 18.0��, HVAC mode = '<unset>'.
15:53:45: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}
15:53:45: --- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Cancelled re-sending timer.
15:53:45: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting value 18.0�� (left tries = 11, interval = 30).
15:53:45: <-- [R:Wohnzimmer] [A:climate.wohnzimmer_thermostat_1] Setting temperature = 18.0��, HVAC mode = '<unset>'.
15:53:57: --- [R:Wohnzimmer] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.wohnzimmer_thermostat_1': '18.0', 'climate.wohnzimmer_2_thermostat_2': '19.0', 'climate.wohnzimmer_3_thermostat_3': '18.0'}, 'scheduled_value': '18.0', 'rescheduling_time': None, 'overlay_active': False, 'friendly_name': 'Wohnzimmer'}

All other rooms with “same” rules but only one thermostat work without any problems.

[SaxnPaule]

It’s also strange, that in case of the opened window all thermostats are set to 8° but one minute later the faulty ones return to 21° while the third one stays at 8° whats totally correct.

[roschi]

Hi @SaxnPaule

This looks really weird, and I think there is something going on that’s not included in the logs. For instance, between 15:49 and 15:51 there are no messages, however Schedy would not output “Not sending … redundantly” without something like “Setting value …” before, so I think the log is incomplete.

Could it be that you’ve got two distinct Schedy instances running in parallel which both try to control the same entities? You tweaked the log formatting to not include the app name, so this could easily happen without you really noticing it.

Anyway, if you send me your phone number by mail (search for hass-apps on PyPi and click on the author name in Meta section) I could call you back and maybe try to help you out more effectively.

Best regards
Robert

[Reynald (Reynald RolluS)]

Hello all, and happy new year !

I’d like to have allow_manual_changes set according to an input_boolean.
I tried several options but failed every time

Any guidance please?

Thank you,
Reynald

[SaxnPaule]

@roschi Thanks for your reply. The log is greped for “thermostat_1” to only show corresponding entries.

Before pasting it to the forum, I removed the first part of every line because it’s useless

I only have one instance of schedy running.

I found the root cause. It’s not the plugin. It was again the stupid eq3 max cube. I turned it off and on again, restarted appdaemon and everything works as expected.