Heaty will die, Schedy be born!

@mobile.andrew.jones You may add it to the schedule_prepend section and check against a given list of room names in the expression…

- temp: Break() if room_name in ("foo", "bar", "baz") and is_on("input_boolean.away") else Skip()

Or by exclusion:

- temp: Break() if room_name not in ("cooling") and is_on("input_boolean.away") else Skip()

By saying easier to configure I actually mean remove options that just blow up the documentation without adding real value, such as the master switch, for instance.

1 Like

This is awesome, thank you I’ve read the docs multiple times, but never saw anything about room_name.

@mobile.andrew.jones It’s listed in https://hass-apps.readthedocs.io/en/latest/apps/heaty/temperature-expressions.html

I’ve got a working version ready to migrate to. The docs aren’t completed yet, but if you used Heaty before, you should feel right home.

Here are the docs:
https://hass-apps.readthedocs.io/en/schedy/apps/schedy/index.html

In order to use it, you need to install from GitHub as described in the docs, but you need to use an alternative clone command:

git clone -b schedy https://github.com/efficiosoft/hass-apps

The rest is identical.

Heaty will continue to work simultaneously, because the latest Heaty v0.17.0 is included in that branch as well.

I’ll update the docs bit by bit during the weekend and they’ll be online instantly. Use the upgrading instructions for GitHub-based installations to fetch code updates.

Please be brave, test and - of course - have fun with Schedy!

Best regards
Robert

3 Likes

Ok, the switch and thermostat docs are complete. The docs for the custom and generic actor types have stilll to be written, but that’s not too much work and I’ll do it tomorrow.

Feedback is highly welcome.

Excellent.

Under the Hass.io section it says

Download the observable Python package (version 0.3.2 at least)

The version is 1.0.3 currently and a link would be great observable · PyPI

Under configuration the docs say

Copy the contents of docs/apps/<some_app>/sample-apps.yaml to a new YAML file in your

There isn’t one for schedy.

[edit] Is the idea that the contents of the sample-apps.yaml is added to the existing apps.yaml?

I’d not got as far as installing heaty :smile: so this is first time on a HASSIO VM!

@baz123 Thanks for the feedback.

The thing with observable is soon to be removed, since AppDaemon hopefully gets the proper requirements.txt support soon.

There is indeed a sample-apps.yaml for schedy, you just have to look in the schedy branch until it gets merged to master.

In AppDaemon 3, there is no longer a single apps.yaml, each app you want to run may have its own config instead.

EDIT: You find the sample config with explanations in the docs as well, so you don’t need to search for the yaml files.

Arrgh - rookie mistake, forgot to switch branches :angry:.

I’m seeing this error in the appddaemon log

2018-10-05 22:08:26.084896 INFO AppDaemon: Initializing app schedy using class SchedyApp from module hass_apps_loader
2018-10-05 22:08:26.085504 WARNING AppDaemon: ------------------------------------------------------------
2018-10-05 22:08:26.085968 WARNING AppDaemon: Unexpected error initializing app: schedy:
2018-10-05 22:08:26.086370 WARNING AppDaemon: ------------------------------------------------------------
2018-10-05 22:08:26.087089 WARNING AppDaemon: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 2040, in check_app_updates
    self.init_object(app)
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 1562, in init_object
    app_class = getattr(modname, app_args["class"])
AttributeError: module 'hass_apps_loader' has no attribute 'SchedyApp'

Can I just check I am understanding this;

room:
  room_name:
    actors:
      switch.some-switch:
        schedule:
      switch.another-switch:
        schedule:

@baz123 You don’t run the version from the schedy branch. You either didn’t install it or didn’t restart AppDaemon.

The config’s structure is wrong. a room has a schedule and actors, actors have no schedule… Maybe read the chapter I wrote about the concept.

Ok thanks. Yes I had not restarted appdaemon. Somewhere I read it was not necessary but that will be after it has been restarted the first time :frowning:.

A comment on the structure, having a schedule per room means everything happens at the same time and also means that every actor has to be doing the same thing. If I have a thermostat and a switch in the room, they will have different values and need different schedules.

To control both, I’d need to create ‘virtual’ rooms.

Ah so I have it working sort of (added in an actor type).

I was expecting this to turn a switch off between the times and on otherwise. It is doing the opposite…

      schedule:
      - value: "off"
        start: "23:07"
        end: "23:59"
        name: Fancy Rule
      - value: "on"

[edit] Ah, Timezone is wrong. Logs in UTC and I’m on UTC+1

If you use the switch actor type, that should work.

Rooms are in fact a virtual concept to group actors that should behave identical together. It is also only one actor type allowed per Schedy instance… It’s all explained in the docs really.

1 Like

Hi all,

Apart from the custom actor type that probably will be used rarely anyway, the documentation is complete.

I’ve merged Schedy over to the master branch, hence the usual installation instructions for the development version as written in the docs now count for Schedy as well.

The latest docs are at https://hass-apps.readthedocs.io/en/latest/

You may now switch over from Heaty if you like.

Best regards
Robert

I am finding a problem with the Timezone.

My local time is 10:50 (UTC+1). Using this schedule, the switch is set to ‘off’ on initialisation. If I change the on time to 09:36, the switch initialises to ‘on’

      schedule:
      - value: "on"
        start: "10:36"
        end: "23:59"
        name: Fancy Rule
      - value: "off"

I have tired this loads of different ways. I have set the timezone in AppDaemon to UTC.

I have checked on Timezone settings here.

Schedy seems to be working to the same time as the log timestamps (which are UTC). I’m not sure if these should be local or UTC which may point to my problem.

I have just done a pull from master branch.

Then your system time zone is probably wrong. Please run

date

and post the output. If it’s a Debian-based system, you can configure the timezone with

sudo dpkg-reconfigure tzdata

Edit:
I’ve actually not set a timezone in appdaemon.yaml at all, just configured it in Home Assistant as Europe/Berlin in my case. And the system time zone is of course set correctly as well.

Edit 2:
I see you’re already discussing this in another thread and you’re using hassio. Schedy is definitely not the problem in your case, since AppDaemon gets a wrong time zone. Otherwise, its logs would be in local time as well. So you need to set the correct time zone in Home Assistant. Good luck.

1 Like

Yes thanks. I think it is but it is the VM image so no direct access to the base system. Cheers!

[edit] And working thanks.

I note the readthedocs is missing the schedy instructions and also the pages seem to be missing on the shedy branch of the docs.

As I wrote, it’s in master now. Use the latest docs.

Ah OK. Had not realised that https://hass-apps.readthedocs.io/ <> https://hass-apps.readthedocs.io/en/latest/apps/index.html

Cheers

Hi @roschi,

Is there a way of setting attributes 1,2 & 3 of an entity to x, y & z at one period of time, then set those attributes to a, b & c at a different period of time using Schedy?

Possibly I am going about this the wrong way :frowning:

I have also tried to use the thermostat actor on a generic thermostat. What attribute does the thermostat actor set with the value value?

  module: hass_apps_loader
  class: SchedyApp
  actor_type: thermostat
  rooms:
    sunroom:
      schedule:
      - value: 25
        start: "05:30"
        end: "16:40"
        name: Rule1
      - value: 14
      replicate_changes: true
      reschedule_delay: 1
      actors:
        climate.tank:

Attributes aren’t just set, that wouldn’t trigger any action. The appropriate services are called instead. The thermostat actor’s documentation describes quite comprehensive which services are called with which attributes.

For your other issue, you need to use the custom actor type and implement the actions needed to set the desired attributes yourself. Read the docs. I plan to add an example custom actor sometime, but don’t have time right now.