One second, could it be that the service name has to be upper-case? At least that is how it’s written in the official component docs.
@SebuZet If you like, you could switch over to the development version and try a new feature called “short values” for the generic actor type. That should simplify your schedules greatly.
in HA everything is possible, but it would be quite unexpected, because they use lowercase everywhere.
but it doesnt seem to be a AD problem, but HA doesnt recognize the service.
i have seen some cases in the past where the service needed to be given with a dot instead of a slash.
so like
service: “fan.xiaomi_miio_set_favorite_level”
that could be worth trying.
and i like to see a pic from the dev page showing that service (i know you cant see it, but i can see if its like i expect from a service)
there must be something why HA doesnt recognises that service.
One second, could it be that the service name has to be upper-case? At least that is how it’s written in the official component docs.
That was a problem. Strange for me but whatever. It works 
If you like, you could switch over to the development version and try a new feature called “short values” for the generic actor type. That should simplify your schedules greatly.
I’ll try next week.
that could be worth trying.
and i like to see a pic from the dev page showing that service (i know you cant see it, but i can see if its like i expect from a service)
Here you are:
@roschi @ReneTode, Thank you very much for your help. It works almost perfect but still working on…
Strange, but good to know. So switching to all upper-case resolved it?
Regarding the short values, they just address what we talked about yesterday, some states in which not all slots are required.
Regarding the short values, they just address what we talked about yesterday, some states in which not all slots are required.
That sounds interesting. I suppose that I have to divide my app into two different apps. First will be a regular On/Off switch and the second one will change purifier mode. I have to do this because I’ve noticed that after powering purifier off attribute ‘Speed’ disappear. It makes infinity loop in Schedy with error “Not respecting value change from a sending actor.”
EDIT: My current config. Comments are welcome. I will leave this one as generic actor usage example.
That sounds interesting. I suppose that I have to divide my app into two different apps. First will be a regular On/Off switch and the second one will change purifier mode. I have to do this because I’ve noticed that after powering purifier off attribute ‘Speed’ disappear. It makes infinity loop in Schedy with error “Not respecting value change from a sending actor.”
That’ll be fixed as a side-effect of using short values as well.
EDIT: But keep in mind that it’s a new and experimental feature that hasn’t undergone reasonable testing yet. That’ll be your part. 
glad it worked.
like i said, in HA you never know 
i would also never would have guessed that from the dev page.
So far so good. I’ve switched to develop branch and added short_values in my configuration.
Working very good. I’ll let you know if any issue occur.
Updated config. Tomorrow I will try to simplify calculate_favorite_level snippet.
Thank you @roschi once again for great work, time and help.
Just to be sure, better use the master branch, not dev, as that might be broken at times.
Just to be sure, better use the
masterbranch, notdev, as that might be broken at times.
Of course, I’ll switch to the master branch as soon as short_values will be introduced.
But keep in mind that it’s a new and experimental feature that hasn’t undergone reasonable testing yet. That’ll be your part.
@roschi, I’ve got something. Scenario:
- Current mode: “Off”
- I’ve changed mode to ‘Smart’
- Schedy turned purifier on as expected
- After ~1 sec turned it off
- After a while (probably 30s) turned it on again
Logs:
2019-02-01 14:55:59.778142 INFO Purifier: --> Attribute 'state' of 'input_select.salon_purifier_mode' changed to 'Off', reevaluating <Room R:Salon>.
2019-02-01 14:56:00.193447 INFO Purifier: <-- [R:Salon] Value set to 'off'. [scheduled]
2019-02-01 14:56:00.300595 INFO Purifier: --> [R:Salon] [A:fan.salon_purifier] Received value of ('off', 'favorite', 2).
2019-02-01 15:51:04.407226 INFO Purifier: --> Attribute 'state' of 'input_select.salon_purifier_mode' changed to 'Smart', reevaluating <Room R:Salon>.
2019-02-01 15:51:05.862468 INFO Purifier: <-- [R:Salon] Value set to ('on', 'favorite', 2). [scheduled]
2019-02-01 15:51:05.970925 INFO Purifier: --> [R:Salon] [A:fan.salon_purifier] Received value of ('on', 'favorite', 2).
2019-02-01 15:51:05.994055 INFO Purifier: --> [R:Salon] [A:fan.salon_purifier] Received value of ('off', 'favorite', 2).
2019-02-01 15:51:06.005591 WARNING Purifier: !!! [R:Salon] [A:fan.salon_purifier] VALUe ['off', 'favorite', 2] should be shortened to ('off',), doing it for you now.
2019-02-01 15:51:28.097764 INFO Purifier: --> [R:Salon] [A:fan.salon_purifier] Received value of ('on', 'favorite', 2).
Should I register new issue on GitHub?
BR,
Seba
Of course, I’ll switch to the
masterbranch as soon as short_values will be introduced.
It’s in master. The dev branch is really just for my personal testing and doesn’t work reliably.
Please retry with latest state of master, if it still doesn’t work, open an issue on GitHub.
Ok, now it’s clear. I’ll use official version when new functionality will be available.
Still occurs but expected state is ‘achieved’ after few seconds.
Important thing is that that behavior can be observed only when changing from ‘Off’ state. Maybe device needs more time to turn on and correctly notify new state?
Ok, I really have to go. Have a nice evening and weekend 
Would be extremely helpful to have an issue opened with a debug log (debug: true in the config) and exact timestamp at which you turn on the fan. I can’t resolve it otherwise.
Ofcourse, I will open an issue on GitHub and provide a full log with timestamps. I’m not able to do this right now but will do asap.
EDIT: GitHub issue created
Ok, will look into it next week.
Hey @roschi,
I need some help with watched_entities.
This is my current setting for one of my rooms:
workroom:
friendly_name: Buero
allow_manual_changes: true
actors:
climate.burothermostat:
template: homematic
watched_entities:
- "climate.burothermostat:operation_mode:reset"
schedule:
- v: 22
months: 11-12, 1-4
rules:
- {weekdays: "1-5", start: "18:00", end: "00:00"}
- {weekdays: "6-7", start: "10:00", end: "00:00"}
Additionally, these are my schedule_prepends:
schedule_prepend:
- x: "Abort() if is_off('input_boolean.enable_schedy') else Skip()"
- x: "Abort() if is_off('input_boolean.enable_schedy_' + room_name) else Skip()"
- x: "Abort() if not is_empty(filter_entities('climate', schedy_room=room_name, operation_mode='manual')) else Skip()"
- x: "Mark(OFF, Mark.OVERLAY) if not is_empty(filter_entities('binary_sensor', window_room=room_name, state='on')) else Skip()"
Changing the temperature on the thermostat, without changing the operation_mode, triggers Schedy to reevaluate the room. The log says that Schedy thinks the operation_mode got changed to auto, but I actually only changed the temperature. Maybe Schedy should check if the value actually changed?
EDIT: Ah, and one more little thing: Is there a way to disable the warning message that I disabled operation mode support?
Changing the temperature on the thermostat, without changing the operation_mode, triggers Schedy to reevaluate the room. The log says that Schedy thinks the operation_mode got changed to auto, but I actually only changed the temperature. Maybe Schedy should check if the value actually changed?
That’s interesting. I thought that AppDaemon only triggers the state listener when the attribute it has been registered for really changed its value… Maybe @ReneTode can clarify this?
EDIT: Ah, and one more little thing: Is there a way to disable the warning message that I disabled operation mode support?
No, you’ll have to live with it.