you know which integration does that? in my config it was version, and that can easily, well, a little bit of work but rather easy, circumvented by using a rest sensor, which update interval you can set your self.
How do you patch it? Do you patch it directly in the container or by copying the integration to your custom_components folder and making the changes there?
If youâre doing it directly in the container, try doing it via custom_components instead and see if it makes a difference.
In this case it was due to a setting in NetworkManager.conf that caused the periodic connectivity check. The documentation appeared to imply one could modify the setting but itâs not possible. Itâs a standard feature in Debian, Ubuntu, etc except itâs not enabled by default (whereas it is enabled in Home Assistant OS).
Iâm patching it in Supervisorâs container (using a shell script).
Are you suggesting one can run Supervisor like a custom component? My first thought would be ânot possibleâ because itâs not an integration.
The homekit_controller integration resides in the core container and that still permits patching ⌠but I think that may not last.
Sorry, Iâm losing track between this thread, the issues tracker, and Reddit. Are you using the newer Tasmota integration or just the âolderâ MQTT way? Iâm not seeing what youâre describing in one of my lights that is using the newer Tasmota integration - but it could be a difference in our bulbs (RGBW vs RGB CCT). After testing yesterday, I just decided to migrate over to the new integration since itâll probably get better support in the future and I like some of the additional sensors and the way it groups the plugs in my smart power strips.
Sorry, I misread your post. I though you were getting this when patching integrations rather than the Supervisor itself. I donât think patching that would work via custom_components, that would only work for integrations.
It may work if they implement the same checking for the core container in future and that causes errors when patching integrations.
After update got a lot of such messages:
Traceback (most recent call last):
File â/usr/local/lib/python3.8/concurrent/futures/thread.pyâ, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File â/usr/src/homeassistant/homeassistant/components/modbus/sensor.pyâ, line 232, in
self.hass, lambda arg: self._update(), self._scan_interval
File â/usr/src/homeassistant/homeassistant/components/modbus/sensor.pyâ, line 300, in _update
registers = self._swap_registers(result.registers)
AttributeError: âModbusIOExceptionâ object has no attribute âregistersâ
OK.
I tried downgrading to 2021.4.6, and that didnât solve the problem.
I disabled the Tasmota integration and that did fix the UI controls for RGBW bulbs configured with the Mosquitto MQTT integration - so it looks like the Tasmota integration may be spilling over into affecting devices not assigned to it (and sending the incorrect sequence of MQTT commands).
Having delved into some MQTT debugging and watching what MQTT commands are sent when using the bulbâs UI colour picker (for and RGBW Tasmota bulb configured with MQTT integration). Here is what I found:
- When Tasmota integration is disabled, HA core v 2021.4.6 (RGBW bulb functions properly)
When a color is picked (or brightness is changed while the bulb is set to an RGB colour), two MQTT commands are sent (all âxâ below are integer values being sent with the commands):
RGBW_Tasmota_Bulb_1/cmnd/Color2 x,x,x
RGBW_Tasmota_Bulb_1/cmnd/Dimmer x
When the white level is set (or brighteness changed while the bulb is white), two MQTT commands are sent:
RGBW_Tasmota_Bulb_1/cmnd/White x
RGBW_Tasmota_Bulb_1/cmnd/Dimmer x
This all works correctly and is how Tasmota commands need to be sent (separating RGB (3 channel) and White (4th channel) of the 4 RGBW channels as separate operations).
- When Tasmota integration is ENABLED (bulb malfunctions flickering back to white whenever you try to pick an RGB colour)
When a color is picked, these 3 MQTT commands are sent, in this order:
RGBW_Tasmota_Bulb_1/cmnd/Color2 x,x,x
RGBW_Tasmota_Bulb_1/cmnd/Dimmer x
RGBW_Tasmota_Bulb_1/cmnd/White x
Note the bug with the extra âWhiteâ command at the end,
which changes the RGB colour of the bulb extremely briefly before changing it back to white.
(Changes to brightness of the white bulb work OK and send the correct âWhiteâ and âDimmerâ Tasmota MQTT commands, but the colour canât be changed from the UI)
For anyone else having this problem, Iâve fixed it for my own situation for now by deleting the Tasmota integration (and reverting the few test Tasmota integration devices I had back to the MQTT integration together with âSetOption19 1â (from the each deviceâs Tasmota console) to revert to MQTT autodiscovery and config) and downgrading to HA core v2021.4.6 for now.
Update: After trying to upgrade to core v2021.5.1 again, with Tasmota integration removed, the problem returned again. So there seems to be a problem with the way the v2021.5.1 UI colour picker for RGBW bulbs interface with Tasmota bulbs (sending the extra/problematic âWhiteâ command whenever an RGB colour is picked). I havenât yet been able to find the documentation on how HA expects RGBW bulbs to be configured to work with the new colour pickers (and once âwhite_valueâ is deprecated for the way HA handles bulbs in future).
If someone can find how HA now expects RGBW bulbs to be set up, I can look at whether there is a compatible device and MQQT config for these Tasmota bulbs.
1 Like
Thanks for the suggestion. Itâs seem that itâs already reported and open:
Sadly, I have never used the Tasmota integration and have this issue. All devices were installed with SetOption19.
Sorry. I just updated my post (after several reboots, the problem returned).
As noted in the update I added to the previous post, the RGBW picker has now changed the commands it sends (which I guess might be part of the transition to deprecating support for âwhite_valueâ on 4 channel RGBW bulbs).
I havenât yet been able to find documentation on how HA expects RGBW to be set up to handle these changes (and Iâve had to revert to core v2021.4.6 because the May release has broken too many essential automations for me).
Agreed - just updated the github issue and to me it makes sense to continue there rather than here in the âgeneralâ update thread.
since Waze Traveltime is now updated hard coded each 5 minutes, I suppose out hard become less reliable for smaller distances (kids biking home from school etc etc) and faster movement than can be accurately calculated per that time period.
has anyone found a reliable way to update the sensors âon demandâ so this would again be a useful notification?
- alias: Marijn bijna thuis
id: Marijn bijna thuis
trigger:
platform: numeric_state
entity_id: proximity.marijn_home.
below: 5
condition:
- >
{{state_attr('proximity.marijn_home','dir_of_travel') == 'towards' and
states('device_tracker.life360_marijn') != 'home'}}
- condition: state
entity_id: input_boolean.notify_presence
state: 'on'
action:
service: notify.w_m
data:
message: >-
Marijn is op {{states('proximity.marijn_home')}} km van huis,
en is over {{states('sensor.waze_marijn_home')}} minuten thuis!
I could first add an update entity to the action list, but it will not be switft enough to be followed by the notification. Could add a generic delay in between, but that seems not very intelligent.
interested to see what you all have changed to accommodate this
Thanks, i did open port but was missing ssl option. Thank you for pointing that out 
decided to give this a try, automatically update the waze sensors, based on the related proximity sensors, which use the iOS app, or life360 sensors, which in their place update on move/location in quasi real time:
- alias: Update Waze sensors
id: Update Waze sensors
trigger:
platform: state
entity_id:
- proximity.wife_home
- proximity.marijn_home
- proximity.daughter1_home
- proximity.daughter2_home
- proximity.daughter3_home
- proximity.daughter4_home
condition:
# seems superfluous, but just in case..
- >
{{trigger.to_state.attributes.dir_of_travel != 'stationary'}}
action:
service: homeassistant.update_entity
data:
entity_id: >
sensor.waze_{{trigger.to_state.object_id}}
Google travel time doesnât seem to work anymore with dynamic destinations
This used to be my config, got imported without errors.
sensor:
# - platform: google_travel_time
# scan_interval: 900
# api_key: !secret google_apikey
# origin: device_tracker.467cfa38bbada1bf
# destination: sensor.cal_location
# name: google_travel_time_driving
it just doesnât recalculate after the destination is updated ( from google calendar appointment destination, I set that with a template sensor)
there are breaking changes mentioned about travel time. and about being setup from the UI, i presume you have checked that first. 2021.5: Stability, performance, triggers, color modes! - Home Assistant
yeah, just re-read them as well, only mentions itâs not longer possible to configure from yaml, not other details.
you may need to remake the sensors based upon the new ones
Hi , sorry , which custom component are you using , i lost climate entity too of my hive.
Thanks