0.113: Automations & Scripts, and even more performance!

[MarkB1 (Mark Booth)]

@pergola.fabio

you guys dont have issues with Tuya? i see a lot of errors like below , sometimes it works, sometimes errors

No, managed to get rid of all my TUYA stuff…

[petro]

EDIT: Disregard.

[jwelter (John Welter)]

This explanation has answered so many “why did it do that?” from the past – thank you! And thanks for the great new extensions to scripts and automations.

[ronschaeffer]

Well, that was a long and confusing manual migration to the new way of configuring RFXtrx…

Some tips based on my experience for others starting the migration:

• Move your devices under rfxtrx: in configuration.yaml one or very few at a time. There is no obvious relationship between the event codes that you put in configuration.yaml for each or your devices and the automatically generated device/entity names in the UI. If you add more that one at the same time, it appears impossible to know which is which without running around to press various buttons, activate sensors, etc., and watching the behavior in the UI. Yes, you have to restart HA each time, but it’s worth it.

• It is safe to disable automatically created entities which are not actually used. For my LightwaveRF Gen 1 wall light switches, PT-2262 buttons and PT-2262 motion sensors, the integration created three entities for each device:

  1. Switch - Never changes state; I disable it.
  2. Binary sensor - Changed state when pressed or activated; Left it enabled.
  3. Sensor for RSSI - Most of my devices don’t report RSSI. Disabled it when not reported.

• Several of my PT-2262 devices do not have different on/off device IDs as described in the documentation. Instead of the device ID changing, it’s the event code that changes. Nevertheless, if you put the first event code (or perhaps also any of the others?) as the device in your configuration.yaml, it will still work even though the code changes. The binary sensor changes to ‘on’ when pressed. You can have it turn off automatically with an off-delay in your configuration.yaml. It then works well as a trigger without command_on and command_off in the configuration.

• As reported earlier by @Ernst, you can correct light devices being recognized as switches by editing the event code in your configuration.yaml. Oddly, even when my devices were of the same brand and model, some would be recognized as switches and others as lights.

[carlos.vroque]

I have the same issue here. Seems that Tuya is just not a reliable solution in HA.

[tom_l]

Have any of you having trouble with Tuya tried this?

TuyaGateway v2.0 now available

Hi All, I (with the help of a few others) developed TuyaGateway. A python server that talks to your tuya devices on one side and MQTT on the other. TuyaGateway uses TuyaFace to connect with the devices. TuyaFace is the rewritten variant of the much used, and not very well working python-tuya library. With an additional (web)application (GismoCaster) the configuration can be created for both the gateway and Home Assistant (discovery). Below a quick overview of the goodies. [image] I’ve a limi…

[francisp (Francis)]

I tried it, but it only works if you have a tuya protocol version 3.1 or 3.3. device. If you have a tuya protocol 3.2 device, it does not work.

Add support for v3.2 protocol

[pnbruckner (Phil)]

@mmcpro

Although previous version was more like restart

Not really. FWIW, if an automation contained no delay or wait_template steps, then it was really more like parallel. Even if it did contain a delay or wait_template, it was parallel up until the delay or wait_template, and then it was just, well, broken, because the next trigger would abort the delay/wait and continue to the next step.

[pnbruckner (Phil)]

@KennethLavrsen

What I meant with the documentation was that the new feature had examples only using state changes and I had to spend some time putting the things together (based on the exact docs you link to).

I encourage to use more complete examples in the documentation in general. I remember how it was a year ago when I started. The fully working examples on this forum and the github configs many have shared have been a life saver for me.

It’s on my list to go over all the existing automation & script examples and update them with the new features. They are a bit scattered, so it will take some time. And I wanted to focus on dealing with any issues that pop up first. No matter how much testing one does (and I, with the help of some “alpha” testers, did a lot of testing before these features “hit the streets”), there’s always going to be something overlooked once it gets into a lot of hands. But, yes, that definitely needs to be done!

@KennethLavrsen

I have more than 20 remotes and there is also some value in having the exact same yaml structure in all of them. If you try to be too smart, and come back in 6 months to tweak something then it becomes more difficult to maintain. Sometimes 5 lines of code is better than being smart and compact

I completely agree! Although I have seen a tendency for people to use the more complex, albeit feature right, choose action when the same thing can be done much more simply with a service or data template.

[pnbruckner (Phil)]

@MarkB1

I’m suspecting the Amcrest Integration?

How so? I don’t see anything related to amcrest in the log snippet you shared.

[MarkB1 (Mark Booth)]

I do not get the >10 min wait to complete loading with the component committed, tried it on two different instances.
As soon as I re enter the Amcrest Integration and reboot I then get the issue with it taking forever to load then once it does responsiveness and lag are an issue as well as increased CPU load, Memory and CPU temperature raised?

Might just be coincidence but 0.113.0 has thrown me so many other log entries I’m just trying to work my way through all of them.

[GordonTGopher (Gordon W)]

Everyone is welcome to join the beta The more configurations that beta software is tested with the more likely it is that any faults will be found before the full release.

[pnbruckner (Phil)]

Ok, thanks. If you can make any concrete correlations between the amcrest integration and the problems you’re experiencing (I mean with enough details that can help indicate how they are connected), then by all means, please open an issue. I work on that integration, too. You might try adding this to your configuration:

logger:
  default: info # or whatever default level you like
  logs:
    amcrest: debug
    homeassistant.components.amcrest: debug

Then, after restarting, if you look in home-assistant.log you might get some more clues.

[planar (Balazs Adam)]

After upgrading to 0.113, my Gauges changed a bit and messed up my layout. The name of the gauge now being shown under the gauge at the same time the gauge itself is smaller. Tried changing the font-size with card mode without any luck.

Can anyone hep understand why this is happening?

[Mediacj]

Thanks for sharing your migration!

I have so many sensors etc, this is not working for me. For now I go back to the previous release and hopefully there will be an easier migration available in near future.

EDIT: I decided to migrate now, it took me 2 hours but after all it’s working fine!

[matisaul (Matias Saul)]

Same problem here… I tried with Tuya custom component, but it is the same.

[123 (Taras)]

Here’s another approach that uses scripts and a traditional service_template.

#automation:
- alias: 'Bedroom Dimmer'
  initial_state: 'on'
  trigger:
    platform: event
    event_type: deconz_event
    event_data:
      id: bedroom_switch
  action:
    service_template: "script.button_{{trigger.event.data.event}}"

#script:
  button_1001:
    alias: 'Set bedroom lighting 1001'
    sequence:
      - service: light.turn_on
        data:
          entity_id:
            - light.bedroom
          brightness_pct: 100

  button_1002:
    alias: 'Set bedroom lighting 1002'
    sequence:
      - service: light.turn_on
        data:
          entity_id:
            - light.bedroom
          brightness_pct: 50

It’s effectively the same as using choose; the event code determines which set of actions to perform. The principal difference is that the actions (the scripts) are separate from the automation. It’s more modular (more than one automation can call the same script, thereby the script serves as a sole source of truth) but, if consolidation is preferred, choose allows all actions to reside in one automation.

[pergola.fabio]

I am trying to ignore does messages for that specific switch in log, since everything is working as expected though… Just don’t know how to exlude that single switch from error in logger:

[MarkB1 (Mark Booth)]

So put the integration back in 0.113.0 and the debugging components tested config before restarting, everything okay.

On restart

20-07-24 16:06:35 INFO (SyncWorker_2) [supervisor.docker.interface] Restart homeassistant/raspberrypi4-homeassistant
20-07-24 16:06:35 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Received message 8:1000 is not str
20-07-24 16:06:35 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
20-07-24 16:07:04 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation in progress
20-07-24 16:07:20 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation done
20-07-24 16:07:25 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation in progress
20-07-24 16:07:46 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation done
20-07-24 16:17:49 WARNING (MainThread) [supervisor.homeassistant] Don't wait anymore of Home Assistant startup!
20-07-24 16:17:49 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-347464' coro=<process_lock.<locals>.wrap_api() done, defined at /usr/src/supervisor/supervisor/utils/__init__.py:22> exception=HomeAssistantError()>
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/utils/__init__.py", line 31, in wrap_api
    return await method(api, *args, **kwargs)
  File "/usr/src/supervisor/supervisor/homeassistant.py", line 421, in restart
    await self._block_till_run()
  File "/usr/src/supervisor/supervisor/homeassistant.py", line 638, in _block_till_run
    raise HomeAssistantError()
supervisor.exceptions.HomeAssistantError

how can I attach the log?

[pnbruckner (Phil)]

You can put it on https://hastebin.com/ or https://paste.ubuntu.com/