Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problems with AppDaemon 4.2 #73

Open
bronger opened this issue Jan 19, 2022 · 4 comments
Open

Problems with AppDaemon 4.2 #73

bronger opened this issue Jan 19, 2022 · 4 comments

Comments

@bronger
Copy link

bronger commented Jan 19, 2022

I have the following settings in my schedy.yaml:

    sleeping:
      allow_manual_changes: true
      rescheduling_delay: 10
      actors:
        climate.eurotronic_spzb0001_1975c403_thermostat:
          template: zigbee
      schedule:
        - value: 23
          weekdays: 2-5
          start: "8:00"
          end: "17:00"
        - value: "OFF"
          start: "6:00"
          end: "9:00"
        - value: 18
      watched_entities:
        - climate.eurotronic_spzb0001_1975c403_thermostat

Since AppDaemon 4.2, this does not work anymore:

2022-01-18 17:00:00.146730 INFO schedy: <-- [R:sleeping] Value set to 18.0��.  [scheduled]                                               
2022-01-18 17:00:02.417154 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 18.0��.   
2022-01-18 17:00:02.592938 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 23.0��.   
2022-01-18 17:00:02.621737 INFO schedy: --- [R:sleeping] Re-applying the schedule not before 17:10:02 (in 0:10:00).                      
2022-01-18 17:10:03.048137 INFO schedy: <-- [R:sleeping] Value set to 18.0��.  [scheduled]                                               
2022-01-18 17:10:04.229819 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 18.0��.   
2022-01-18 17:10:04.446016 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 23.0��.
2022-01-18 17:10:04.452730 INFO schedy: --- [R:sleeping] Re-applying the schedule not before 17:20:04 (in 0:10:00).

(And so on and so forth.) Downgrading to Appdaemon 4.1 restores the correct behaviour:

2022-01-18 20:41:24.736323 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 23.0��.   
2022-01-18 20:41:28.178263 INFO schedy: <-- [R:sleeping] Value set to 18.0��.  [scheduled]                                               
2022-01-18 20:41:28.301263 INFO schedy: --> [R:sleeping] [A:climate.eurotronic_spzb0001_1975c403_thermostat] Received value of 18.0��.

(And it keeps the 18.0.)
@bronger
Copy link
Author

bronger commented Jan 19, 2022

This is copied (and possibly moved here eventually) from AppDaemon/appdaemon#1467.

@bronger bronger mentioned this issue Jan 19, 2022
Closed
@Julius112
Copy link

Julius112 commented Jan 20, 2022 •
edited
Loading

Hi,

I can see that you have the Eurotronics Spirit Zigbee Thermostat. I have the same Thermostats and I can confirm having the same problems.

Moreover, I can see a weird behaviour when adjusting the temperature manually on the valve. It then updates the desired temperature in HA, but sets it back to the last setting applied from HA after 10-20 mins. After 2-3 mins it then sets it back to the temperature, which is set on the valve. It toggles like that until a new temperature is set from HA.

I could see this behaviour prior to using schedy, so I think it might be an issue of HA/ZHA (or my misunderstanding of the current_temperature_setpoint and the occupied_heating_setpoint).

This is what I can see when setting the temperature from 19.0 to 21.0:

   1897 2021-12-09 16:51:43 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.SUCCESS: 0>)
   1898 2021-12-09 16:51:43 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataConfirm.Callback(Status=<Status.SUCCESS: 0>, Endpoint=1, TSN=67)
   1899 2021-12-09 16:51:47 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.IncomingMsg.Callback(GroupId=0x0000, ClusterId=513, SrcAddr=0x4539, SrcEndpoint=1, DstEndpoint=1, WasBroadcast=<Bool.false: 0>, LQI=90, SecurityUse=<Bool.false: 0>, TimeStamp=9833555, TSN=0, Data=b'\x1C\x37\x10
   1899 \x5A\x0A\x03\x40\x29\x34\x08', MacSrcAddr=0x4539, MsgResultRadius=29)
   1900 2021-12-09 16:51:47 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=True is_reply=True disable_default_response=True> manufacturer=4151 tsn=90 command_id=Command.Report_Attributes>
   1901 2021-12-09 16:51:47 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] ZCL request 0x000a: [[Attribute(attrid=16387, value=<TypeValue type=int16s, value=2100>)]]
   1902 2021-12-09 16:51:47 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] Attribute report received: current_temperature_setpoint=2100
   1903 2021-12-09 16:51:47 DEBUG (MainThread) [zhaquirks.eurotronic] update attribute 4003 to 2100... 
   1904 2021-12-09 16:51:47 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x4539:1:0x0201]: Attribute report 'ThermostatCluster'[occupied_heating_setpoint] = 2100
   1905 2021-12-09 16:51:47 DEBUG (MainThread) [zhaquirks.eurotronic] update attribute 4003 to 2100... [ ok ]
   1906 2021-12-09 16:51:47 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x4539:1:0x0201]: Attribute report 'ThermostatCluster'[current_temperature_setpoint] = 2100
   1907 2021-12-09 16:51:47 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.heizung_bad_thermostat: Attribute 'occupied_heating_setpoint' = 2100 update
   1908 2021-12-09 16:51:47 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.heizung_bad_thermostat, old_state=<state climate.heizung_bad_thermostat=heat; hvac_modes=('off', 'heat'), min_temp=5.0, max_temp=30.0, current_temperature=21.2, temperatu
   1908 re=19.0, hvac_action=idle, system_mode=[4]/heat, occupied_cooling_setpoint=2600, occupied_heating_setpoint=1900, pi_heating_demand=0, unoccupied_cooling_setpoint=1600, friendly_name=Heizung Bad thermostat, supported_features=1 @ 2021-12-09T16:45:08.648695+01:00>, new_state=<state clima
   1908 te.heizung_bad_thermostat=heat; hvac_modes=('off', 'heat'), min_temp=5.0, max_temp=30.0, current_temperature=21.2, temperature=21.0, hvac_action=idle, system_mode=[4]/heat, occupied_cooling_setpoint=2600, occupied_heating_setpoint=2100, pi_heating_demand=0, unoccupied_cooling_setpoint=
   1908 1600, friendly_name=Heizung Bad thermostat, supported_features=1 @ 2021-12-09T16:45:08.648695+01:00>>
   1909 2021-12-09 16:51:47 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.heizung_bad_thermostat: Attribute 'current_temperature_setpoint' = 2100 update

And then after some minutes:

   2499 2021-12-09 17:09:34 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
   2500 2021-12-09 17:09:34 DEBUG (MainThread) [zigpy_znp.api] Received command: SYS.Ping.Rsp(Capabilities=<MTCapabilities.APP_CNF|GP|UTIL|ZDO|AF|SYS: 1625>)
   2501 2021-12-09 17:09:57 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.IncomingMsg.Callback(GroupId=0x0000, ClusterId=513, SrcAddr=0x4539, SrcEndpoint=1, DstEndpoint=1, WasBroadcast=<Bool.false: 0>, LQI=93, SecurityUse=<Bool.false: 0>, TimeStamp=15023339, TSN=0, Data=b'\x18\x49\x0
   2501 A\x12\x00\x29\x6C\x07', MacSrcAddr=0x4539, MsgResultRadius=29)
   2502 2021-12-09 17:09:57 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=73 command_id=Command.Report_Attributes>
   2503 2021-12-09 17:09:57 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] ZCL request 0x000a: [[Attribute(attrid=18, value=<TypeValue type=int16s, value=1900>)]]
   2504 2021-12-09 17:09:57 DEBUG (MainThread) [zigpy.zcl] [0x4539:1:0x0201] Attribute report received: occupied_heating_setpoint=1900
   2505 2021-12-09 17:09:57 DEBUG (MainThread) [zhaquirks.eurotronic] update attribute 0012 to 1900... 
   2506 2021-12-09 17:09:57 DEBUG (MainThread) [zhaquirks.eurotronic] update attribute 0012 to 1900... [ ok ]
   2507 2021-12-09 17:09:57 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x4539:1:0x0201]: Attribute report 'ThermostatCluster'[occupied_heating_setpoint] = 1900
   2508 2021-12-09 17:09:57 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.heizung_bad_thermostat: Attribute 'occupied_heating_setpoint' = 1900 update
   2509 2021-12-09 17:09:57 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.heizung_bad_thermostat, old_state=<state climate.heizung_bad_thermostat=heat; hvac_modes=('off', 'heat'), min_temp=5.0, max_temp=30.0, current_temperature=21.0, temperatu
   2509 re=21.0, hvac_action=heating, system_mode=[4]/heat, occupied_cooling_setpoint=2600, occupied_heating_setpoint=2100, pi_heating_demand=45, unoccupied_cooling_setpoint=1600, friendly_name=Heizung Bad thermostat, supported_features=1 @ 2021-12-09T16:45:08.648695+01:00>, new_state=<state c
   2509 limate.heizung_bad_thermostat=heat; hvac_modes=('off', 'heat'), min_temp=5.0, max_temp=30.0, current_temperature=21.0, temperature=19.0, hvac_action=heating, system_mode=[4]/heat, occupied_cooling_setpoint=2600, occupied_heating_setpoint=1900, pi_heating_demand=45, unoccupied_cooling_s
   2509 etpoint=1600, friendly_name=Heizung Bad thermostat, supported_features=1 @ 2021-12-09T16:45:08.648695+01:00>>

I hope I'm not completely misleading here but it might be some problem with the mapping of these two attributes...

@bronger
Copy link
Author

bronger commented Jan 20, 2022

Does downgrading to AppDaemon 4.1 help you, too?

@Julius112
Copy link

Yes - in some way. I've also updated HA to 2021.12 and haven't checked this behaviour described above yet.

Downgrading AppDaemon 4.1, at least, leads to a different, more functional, but still problematic solution (as I'm then running into #62 ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bronger @Julius112