IoTaWatt core integration bugs can't be fixed with current HA/IoTaWatt policies in place - remove from core?

[Aephir]

The problem

As it seems that the combination of IoTaWatt and Home Assistant policy will never allow the bugs in the IoTaWatt core integration to be fixed (relating to unique ID, see links to discussions below), I would suggest that the integration be removed from Home Assistant Core.

There is a working custom component that does not have this issue, so removing would not mean that we can't use IoTaWatt in HA.

See these threads for discussions and conclusions that this will never be able to work as is:

Entire thread #87182 and links therein.
#86834 (comment)

What version of Home Assistant Core has the issue?

All

What was the last working version of Home Assistant Core?

None

What type of installation are you running?

Home Assistant OS

Integration causing the issue

IoTaWatt

Link to integration documentation on our website

https://www.home-assistant.io/integrations/iotawatt/

Diagnostics information

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:540
Integration: Sensor (documentation, issues)
First occurred: 16:51:03 (3 occurrences)
Last logged: 16:51:03

Platform iotawatt does not generate unique IDs. ID 8CCE4EF8DE4C-input-1-WattHours already exists - ignoring sensor.iotawatt_input_1_wh
Platform iotawatt does not generate unique IDs. ID 8CCE4EF8DE4C-input-2-WattHours already exists - ignoring sensor.iotawatt_input_2_wh
Platform iotawatt does not generate unique IDs. ID 8CCE4EF8DE4C-input-3-WattHours already exists - ignoring sensor.iotawatt_input_3_wh

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @gtdiehl, @jyavenard, mind taking a look at this issue as it has been labeled with an integration (iotawatt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of iotawatt can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign iotawatt Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

iotawatt documentation
iotawatt source
_{^{(message by IssueLinks)}}

[jyavenard]

The custom component hasn't been updated in years. It's no longer ready for public consumption.

That the core version has this specific issue is minor IMHO. And there are workaround to customise how a sensor looks which is the only downside to not having unique id.

Your precious submissions to this component already made it worse than what it should be for many(me in particular).

So don't make it any worse.

I strongly oppose this proposal

[jyavenard]

If you want to use the custom component then do so. Don't force others to abide to your personal choice

[Roving-Ronin]

As an interested end user I would have to politely say the official integration is rather useless. Integration should be moved to HACS and involve https://github.com/boblemaire (the guy that makes the IoTaWatt, that is a no brainer for working with).

Saying the custom intergration https://github.com/boblemaire/iotawatt_ha hasn't been updated in years is a bit disingenuous btw, failing to take into account why would the inventor of IoTaWatt bother to update it, when someone else has grabbed his product in regards HA.
Also ignores this update that has been done to work around the items lacking from the 'official' integration: https://github.com/kuralabs/iotawatt_ha

As an end user, an integration that just works is required... not politics and **** measuring contests.

[jyavenard]

Bob Lemaire has dropped development of the IotaWatt, it's no longer for sale either. Getting him involved for any future update is wishful at best.

when someone else has grabbed his product in regards HA.
Now that is disingenuous (and rather ignorant statement really) when he's been involved all along in the development of this integration.

The integration he hosts is identical to the one I first modified and submitted to HA with the unique_id for output removed.
I was just as disappointed as anyone else that the official integration refused the part that was setting a "unique" id claiming it wasn't unique enough.

But there's a long stretch to declare the integration useless when it does what it needs to do for the vast majority of users. Not everyone wants to deal with HACS and deal with breakage stuff.

That it's in core means that it gets modified whenever it needs to be so it doesn't stop functioning.

Also, I wasn't referring to this clone, but the other "official" HACS one, the one by @gtdiehl (and the last commits there were mine)

[jyavenard]

But I do take offense that because you find an integration useless (because somehow not having unique id for output sensors would make it "useless") that official support must be dropped.
How selfish and self-centred is that !?

[Roving-Ronin]

Functionly wise, when I rebuilt HA from scratch within the last 2 months and the integration only allowed showing the IoTaWatt 'Inputs' (and not the 'Outputs') is was rather well..... useless, let alone the unique_id issue.

As your also aware (your name was again the post that lead to this link), the vendor for IoTaWatt changed his mind and decided to change his sale model only, not discontinue the product, and now is instead selling the product via a number of dealers... see: https://stuff.iotawatt.com/?v=6cc98ba2045f

Also the vendor of IoTaWatt never dropped development of IoTaWatt, he was only wanting to step back from the front line reseller type support that was consuming his time and restricting his ability to work on R&D. He has been working on supporting the ESP8266 version (last update only ~6 weeks ago - https://github.com/boblemaire/IoTaWatt ) and working on a future ESP32 version, that it looks like he's recently worked out how to get the ESP32 (and potentially with Ethernet) version going: https://community.iotawatt.com/t/big-changes-to-esp32-effort/5875

"How selfish and self-centred is that !?" If you can't take feedback and criticism, from how end users find this integration and hence allow for its improvement, I would suggest that you might want to look to yourself in regards those points you raise.

If your still feeling hurt, I provide the following link to complete: http://cdn.ceo.ca.s3-us-west-2.amazonaws.com/1evr10g-Hurt-Feelings-Report.pdf

[Aephir]

I think this is getting a bit off track compared to my intention.

I'm not saying the official integration is "useless", far from it. I've been very happy to have it for a couple of years now and really appreciate that someone took the time to make it! But I do find it quote annoying that it, by default, logs errors. I certainly appreciate that this annoyance can/should be classified as a severe case of "first world problems", but nevertheless, it does bug me.

I agree that the custom component I linked to (last updated 7 months ago, about when it was forked/created), could use a bit of love, e.g., to make it into HACS. But I've used it for a few weeks now, and other than that, it is great.

This suggestion was actually to stop all the arguing and just focus on a version that works without errors, a way to set politics aside. My idea was that if you use IoTaWatt, you are more likely than not to be a bit more "superuser", and be able to install custom components, so I didn't think it would really hurt anyone to not have it in Core.

However, I do get your argument, that having it in core means it stays stable (well, with the errors it has, but that it won't stop working), and that is of course also worth considering.

Can we please just have a discussion of the pros and cons, and see what option makes the most sense? If I'm wrong, and it ends up making more sense keeping it in Core, then that's also perfectly fine with me. I just though it MIGHT make sense to remove, so I wanted to float that suggestion.

[jyavenard]

Can we please just have a discussion of the pros and cons, and see what option makes the most sense? If I'm wrong, and it ends up making more sense keeping it in Core, then that's also perfectly fine with me. I just though it MIGHT make sense to remove, so I wanted to float that suggestion.

My take is : you don't want to use this integration and instead use HACS: simple then, do so.
Don't force people to do the same.

I like a system that runs, update after update without having to worry about needing to fiddle with a custom integration that may break from one version to the next for lack of support.

That the output sensors don't appear under the IotaWatt integration but need to be searched in the list of entities is a minor inconvenience.
Would I like things to be different? sure.
But it's not going to happen, the HA folks have clearly stated as such many times, times to accept things as they are and move on.

[Aephir]

Don't force people to do the same.

I get that sentiment.

My opinion was that it is not a good UX to have an integration from Core that starts throwing errors at you as soon as you set it up, by no fault of the user. Or the integration maintainer(s), in this case. (I had no concerns about outputs)

That said, my opinion was split about 60/40 towards that being the more important part, and I'm probably closer to 50/50 after considering your point about "Core stability".

I'd still like to hear more constructive inputs to this, but I'm also OK just closing the issue if no one else thinks the errors create enough of a UX problem to merit action.

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.