0.108: Logos, Area Pages, Lovelace Entity Card, Lovelace Map History

Blog
224

On every restart of HA I am getting a newly discovered IPP printer, it is just a duplicate of the already added one. If I add, it adds another instance with these errors in the logs:

* Entity id already exists - ignoring: sensor.hp_photosmart_b110_series_black_ink. Platform ipp does not generate unique IDs
* Entity id already exists - ignoring: sensor.hp_photosmart_b110_series_cyan_ink. Platform ipp does not generate unique IDs
* Entity id already exists - ignoring: sensor.hp_photosmart_b110_series_magenta_ink. Platform ipp does not generate unique IDs
* Entity id already exists - ignoring: sensor.hp_photosmart_b110_series_yellow_ink. Platform ipp does not generate unique IDs
* Entity id already exists - ignoring: sensor.hp_photosmart_b110_series. Platform ipp does not generate unique IDs
225

thanks, couldn’t find it first time, saw it now :slight_smile:

226

so it seems, there is a problem in modbus rtu component and has suddenly stopped working in 0.108.0. This problem has been observed by many users. I also tried 108.1 & 108.2 but the component is still broken. This shows in logs.
WARNING (MainThread) [pymodbus.client.asynchronous] Not Importing deprecated clients. Dependency Twisted is not Installed

 ERROR (MainThread) [homeassistant.setup] Error during setup of component modbus
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 171, in _async_setup_component
    hass, processed_config
  File "/usr/src/homeassistant/homeassistant/components/modbus/__init__.py", line 139, in async_setup
    await hass.async_add_executor_job(start_modbus)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/modbus/__init__.py", line 111, in start_modbus
    client.setup()
  File "/usr/src/homeassistant/homeassistant/components/modbus/__init__.py", line 207, in setup
    loop=self._loop,
  File "/usr/local/lib/python3.7/site-packages/pymodbus/client/asynchronous/serial.py", line 75, in __new__
    yieldable = factory_class(framer=framer, port=port, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/pymodbus/client/asynchronous/factory/serial.py", line 104, in async_io_factory
    client = AsyncioModbusSerialClient(port, proto_cls, framer, loop, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/pymodbus/client/asynchronous/asyncio/__init__.py", line 689, in __init__
    self._connected_event = asyncio.Event()
  File "/usr/local/lib/python3.7/asyncio/locks.py", line 249, in __init__
    self._loop = events.get_event_loop()
  File "/usr/local/lib/python3.7/asyncio/events.py", line 644, in get_event_loop
    % threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'SyncWorker_3'.

my config:

modbus:
  name: binu1
  type: serial
  method: rtu
  port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
  baudrate: 9600
  stopbits: 1
  bytesize: 8
  parity: N
-switch:
  - platform: modbus
    scan_interval: 5
    coils:
      - name: geyser
        hub: binu1
        slave: 1
        coil: 0
    registers:
      - name: first_ac      
        hub: binu1
        slave: 2
        register: 0
        command_on: 1
        command_off: 0
      - name: second_ac      
        hub: binu1
        slave: 2
        register: 1
        command_on: 1
        command_off: 0

on starting a notification says this:

Invalid config

The following integrations and platforms could not be set up:

* [modbus](https://www.home-assistant.io/integrations/modbus)
* modbus.switch

Please check your config.

I am running on Ubuntu 18.04.4 LTS docker
Anyone found the fix yet? kindly suggest?

227

This looks to be a bug with Google cast discovery, not with the vizio integration itself. You may want to open an issue on the GH issue tracker so someone can dig in: https://github.com/home-assistant/core/issues/new?template=BUG_REPORT.md

I did see someone else report a cast issue with 0.108 but not sure if it’s related: https://github.com/home-assistant/core/issues/33617

228

@docvipul

Just checking was this a typo or is this how your current config is/was working before?

It should be just:

switch:

Beyond that I am aware there are modbus problems but for me my config (with hundreds of modbus entities) and 0.108.1 had severe problems so I have just reinstated 0.107.7 for now. Waiting to read some fixes in later releases of 0.108.x to try again.

229

I wouldn’t know; ask one.

1 Like
231

I did. Speak directly to the developer who you believe has broken their promise.

232

yaml v ui still ongoing? give it a rest guys/

it been stated before, its up to the developer of an integration which method they wish to support.

do we want these developers to say stuff it and leave an integration to die if they are forced to support both?

i dont

2 Likes
233

Thanks for your reply. please ignore the ‘-’ in switch: it is a typo :pensive:. I too rolled back to 0.107.7 for now and waiting for a definite fix.

234

Your welcome. From past experience it may take some time for any action on modbus issues…the priority for the modbus integration seems to be very low.

235

In spite of it being the most robust, reliable and time-tested system in automation :slightly_smiling_face:.

1 Like
236

@aidbish Do we really want developers who only want to build a fancy toy with a snazzy looking UI that suits only tech beginners who are not prepared to roll their sleeves up and learn a bit (and will soon tire of their boring toy anyway)?

While it seems to me there are plenty of other developers here who are keen to help build a totally customisable and powerful machine that can do literally anything for multitude of power users who will be around for a long time?

237

Are you a developer?
I am not, so i do appreciate every developer who develops here.
Saying they only want to build snazzy looking UI is not only insulting but condescending to what those guys do.

And some of theose tech beginners who simplifying HA is what they want have been here a lot longer than you or I.

5 Likes
238

This morning I got up to find my alexa intergration had stopped working. I’m using the haaska smart home intergration, and it’s been working for years.

When I browse to - https://myHA.duckdns.org/api/alexa/smart_home

I get - 405: Method Not Allowed

Alexa cannot communicate with any of my devices.

What is also weird is that my front end through the browser has seemed to become unavailable for 10-30 seconds a few times today. Also my iPhone app has done the same thing. I feel like there may be something else going on with HA and this is just a symptom.

I updated to 108.1 yesterday, and 108.2 this morning. Still the same issue.

EDIT: Not a fully scientific testing, but it does seem if I ask my alexa to turn on/off a light/switch after it comes back letting me know that it’s not responding, my frontend is likely to also “stop responding” for a bit. I have to refresh the page several times before it comes back.

239

Not sure if this would help, but this is the error from the amazon lamda site

raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='myHAname.duckdns.org', port=443): Max retries exceeded with url: /api/alexa/smart_home (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f72bee9abcd>: Failed to establish a new connection: [Errno -2] Name or service not known',))
240

@aidbish I am not a developer and FYI I appreciate every developer who has produced the amazingly useful HA we now have to use.

I am simply a user who needs every bit of the present capabilities HA provides.

Reducing the ability of users to adequately control (by customisation of their YAML config) is what’s condescending buddy, especially when the head honcho has made it publicly clear YAML will not be depracated.

I also think anyone (including tech beginners) who has been here a while will know more than you or I by now.

241

@docvipul @wellsy

The Modbus Component has without a doubt been a little slow in HA. At times a work-around or two has been required. Sorry dont have one here. To think there was a time when it only supported one hub! It appears @janiversen has been very active and instrumental in making this component async (as much as it can be). Shout out to all the devs working on this integration! When it comes out of the wash it will be much better. docvipul I am getting the error too and there appears to be an issue with RTU over TCP at the moment as well.

Apr 10 13:25:44 pi hass[10672]: Traceback (most recent call last):
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/homeassistant/setup.py", line 171, in _async_setup_component
Apr 10 13:25:44 pi hass[10672]:     hass, processed_config
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/homeassistant/components/modbus/__init__.py", line 139, in async_setup
Apr 10 13:25:44 pi hass[10672]:     await hass.async_add_executor_job(start_modbus)
Apr 10 13:25:44 pi hass[10672]:   File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
Apr 10 13:25:44 pi hass[10672]:     result = self.fn(*self.args, **self.kwargs)
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/homeassistant/components/modbus/__init__.py", line 111, in start_modbus
Apr 10 13:25:44 pi hass[10672]:     client.setup()
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/homeassistant/components/modbus/__init__.py", line 207, in setup
Apr 10 13:25:44 pi hass[10672]:     loop=self._loop,
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/pymodbus/client/asynchronous/serial.py", line 75, in __new__
Apr 10 13:25:44 pi hass[10672]:     yieldable = factory_class(framer=framer, port=port, **kwargs)
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/pymodbus/client/asynchronous/factory/serial.py", line 104, in async_io_factory
Apr 10 13:25:44 pi hass[10672]:     client = AsyncioModbusSerialClient(port, proto_cls, framer, loop, **kwargs)
Apr 10 13:25:44 pi hass[10672]:   File "/srv/pi/lib/python3.7/site-packages/pymodbus/client/asynchronous/asyncio/__init__.py", line 689, in __init__
Apr 10 13:25:44 pi hass[10672]:     self._connected_event = asyncio.Event()
Apr 10 13:25:44 pi hass[10672]:   File "/usr/lib/python3.7/asyncio/locks.py", line 249, in __init__
Apr 10 13:25:44 pi hass[10672]:     self._loop = events.get_event_loop()
Apr 10 13:25:44 pi hass[10672]:   File "/usr/lib/python3.7/asyncio/events.py", line 644, in get_event_loop
Apr 10 13:25:44 pi hass[10672]:     % threading.current_thread().name)
Apr 10 13:25:44 pi hass[10672]: RuntimeError: There is no current event loop in thread 'SyncWorker_7'.

I keep reverting back to 0.107.6 as I feel there were issues with Modbus 107.7.

242

That head honcho was also the one who said they wont force developers to choose one way or the other. So if a developer chooses to support YAML the option is still there to use YAML, so no its not being deprecated.

1 Like
243

@PtP Of course you were instrumental in the multiple hub workaround which made it into the core…grateful for your work! Interesting about the 107.6 vs 107.7 thing…On my docker I noticed that CPU and memory had gone back to pretty normal - even low levels and I have had zero modbus log entries. What problems are you seeing in 107.7?

244

@aidbish Yes, its highly likely…sadly…the fancy toy will continue to develop and the fantastic machine will decay. Luckily I am only keeping up with the bleeding edge because I have been bitten in the past by not doing so. I’ll just probably stay put on a convenient version and let everyone enjoy the fun.