@evb See the above posts on the smappee integration
Yep, hence why I said:
How do you re-enable a disabled entity?
I disabled an input_number entity and it was removed from everywhere including the States page, Lovelace UI, and the Entities page. So now that it’s gone from the Entities page, and there’s no option in the Entities page to display disabled entities, how do I re-enable it?
You should be able to show it in the integration by clicking on the device and then displaying disabled entities…
I had this issue with disabled entities before. I disabled an input Boolean and had to modify the JSON files in .storage to bring it back. I then disabled an entity in the Synology integration and was able to reenable it from the integration. The third scenario I ran into I think was a PiHole sensor a few versions back and I had to redo the whole integration to get it back. The warning not all integrations support disabling entities is very true. The built-in input_ are definitely the case.
It was an input_number created using Configuration > Helpers so there’s no listed integration or device.
I just learned the answer from SeanM in this post.
On the extreme right hand side of the Entities view there is an icon that I misunderstood to mean sorting. In fact, it means filtering. Clicking it reveals a drop-down menu containing an option to display disabled entities. Easy-peasy.
UPDATE
Re-enabling a disabled entity is not without some caveats.
I re-enabled the disabled input_number.test but its friendly_name was listed as Unavailable instead of Test (what I had supplied when I defined it). Most importantly, it failed to re-appear in the automatically-generated UI (even after executing Reload Input Numbers).
The entity was created using Configuration > Helpers so the expected behavior was for it to be restored to its original functionality (especially after a Reload Input Numbers), but it wasn’t. What fixed it was restarting Home Assistant.
1 Like
Glad to see filtering to show disabled entities is working for certain integrations in this version. It acted different for the input_ integrations a few versions back which forced me to go editing JSON files.
I had xiaomi gateway setup trough yaml, I have comented out that config, discovery did recognize my xiaomi gateway, and I added it with token. Now gateway is visable but none of the sensor show up, all of them unavailable. What am I missing?
- The Smappee integration has been fully rewritten, by @bsmappee themselves!
Shouldn’t there have been a warning that this integration is now behind a pay wall? Breaking change or something. First time I feel left behind by Home Assistant.
Frankly, I agree… It’s frustrating, to say the very least, that I have to pay them to gain access to MY DATA, especially when the monitor was so expensive to begin with. I would definitely suggest emailing smappee ([email protected]) and express your frustrations with the paywall. The more backlash smappee receives the more likely they are to reverse the decision. I emailed smappee about obtaining my api key and am still waiting to hear back on price, however, there is an option to have the data sent directly from the controller via MQTT, but requires having an MQTT server setup to receive the data. I’ve not looked into what requirements there are from HA, but am working on implementing it and should have a write-up soon on how to do it.
After upgrading from 0.108.9 (SV 228) to 0.112 (SV 228) I get this:
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to upgrade. Schema version: 7
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding columns context_parent_id to table events. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Column context_parent_id already exists on events, continuing
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding columns old_state_id to table states. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Column old_state_id already exists on states, continuing
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_events_context_parent_id` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Index ix_events_context_parent_id already exists on events, continuing
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Failed to drop index ix_states_context_id from table states. Schema Migration will continue; this is not a critical operation.
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Failed to drop index ix_states_context_user_id from table states. Schema Migration will continue; this is not a critical operation.
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Failed to drop index ix_states_entity_id from table states. Schema Migration will continue; this is not a critical operation.
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_events_event_type_time_fired` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Index ix_events_event_type_time_fired already exists on events, continuing
2020-07-05 18:11:58 WARNING (Recorder) [homeassistant.components.recorder.migration] Failed to drop index ix_events_event_type from table events. Schema Migration will continue; this is not a critical operation.
2020-07-05 18:11:58 ERROR (Recorder) [homeassistant.components.recorder.util] Error executing query: (MySQLdb._exceptions.IntegrityError) (1364, "Field 'change_id' doesn't have a default value")
[SQL: INSERT INTO schema_changes (schema_version, changed) VALUES (%s, %s)]
[parameters: (8, datetime.datetime(2020, 7, 5, 17, 11, 58, 612330, tzinfo=<UTC>))]
(Background on this error at: http://sqlalche.me/e/gkpj)
2020-07-05 18:11:58 ERROR (Recorder) [homeassistant.components.recorder] Error during connection setup: (MySQLdb._exceptions.IntegrityError) (1364, "Field 'change_id' doesn't have a default value")
[SQL: INSERT INTO schema_changes (schema_version, changed) VALUES (%s, %s)]
[parameters: (8, datetime.datetime(2020, 7, 5, 17, 11, 58, 612330, tzinfo=<UTC>))]
(Background on this error at: http://sqlalche.me/e/gkpj) (retrying in 3 seconds)
Seems the DB migration is not working.
I use a separate MariaDB container (10.5.4) - not the add-on - running as a docker container.
Any ideas anyone?
For the record, seems I use mariaDb and I had to make the column change_id in schema_changes table auto increment to complete the upgrade… there were a load of errors which it claims were not critical, does not exactly inspire confidence tho
Thanks Jonathan, making the column auto increment solved it.
1 Like
homekit problem
Logger: homeassistant.components.homekit
Source: components/homekit/__init__.py:332
Integration: HomeKit Bridge ([documentation](https://www.home-assistant.io/integrations/homekit), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+homekit%22))
First occurred: 12:07:47 (1 occurrences)
Last logged: 12:07:47
HomeKit is not ready. Either it is already running or has been stopped
and tuya switch problem
If they don’t come around, you all could perhaps try grabbing the smappee integration before this change was merged (which looks like June 17) and make it a custom component. Here’s a snapshot:
1 Like
@jamieboy05, I’ve seen it. For me, installing 0.112.2 did resolve for one day the problem…
See topic about it : Smappee sensors no longer working
Thank you! Works for now.
Ps: apparently the integration smappee also breaks HomeKit for some people. HomeKit didn’t start until removal of new smappee integration.
As we now know the HomeKit problem was with smappee integration. Thanks to @bdraco for the search and insight!
After upgrading from 0.112.2 to 0.112.3, my Overview turned into a bunch of red boxes saying “Custom element doesn’t exist: vertical-stack-in-card.” Restarting did not fix it, but reinstalling vertical-stack-in-card from HACS did.