Hi BodgeIT,
Appreciate all the constructive feedback so far. My team and I will do our best to keep the information flowing to this community. Although this coming week we’ll be a little focused on family/relaxing ;-).
Happy Holidays everyone.
5 Likes
Happy holidays to you too.
As far as keeping information flowing, the first thing to do is simply document your websocket api. Just put it on the web. Openness increases sales.
Thanks for coming here and entering the discussion.
1 Like
@BodgeIT @ralfaro If XMPP is officially supported and websocket is not, HA will move back to XMPP. The differences mainly affect developers; users will not be able to tell the difference, assuming implementations of equal quality.
5 Likes
Upgraded to beta firmware and downgraded to 84.3 back to normal just in time for the holiday movies. Thanks Logitech for back tracking a bad idea and sorting out quickly, not many companies care these days
The other option with using beta Harmony firmware is to keep HA on 0.84.6 but copy harmony.py script before the web socket update into /config/custom_components/remote directory.
Anything in custom_components directory will override default components if it exists.
I agree. We’ve been asking for a documented API for at least 3 years. Document it, support it and we’ll use it.
PS I use pyharmony, not HA
Press the fn key at the same time as alt + f9?
This debate is illustrative of a larger debate for home assistant and similar projects.
A large number of components depends on hacked up implementations based on ill defined or reverse engineered functionality. Those implementations are very vulnerable to breakage from any number of causes, just like happened here.
Recently the Xiaomi hub has stopped working for many, possibly due to a firmware upgrade, possibly due to newer devices working differently to the older ones.
A while ago weather underground shat on customers by stopping their free API. Fortunately there are plenty of alternatives, and no one had to bin expensive hardware.
The weather underground example is a case of the all to common bait and switch tactic used by many organisations - provide a free service until you get enough users, then become a monetising bastard using those users data. True people can move from wu, but they have still got thousands of users supplying free data which Wu are selling for a mint.
Anyway, the point is that HA is vulnerable to changes that HA cannot control.
Should the devs limit new components to those who promise to keep their APIs open? And their devices able to communicate with the dreaded ‘cloud’?
2 Likes
I would not be so strict. I imagine instead feature the components using an official API and display a warning on the associated documentation page for the other.
Me too, no lore Logitech for me.
They are good for Mouse and keyboard… err no
1 Like
To be fair on this one… The Wunderground was purchased by The Weather Channel back in 2012 - so I don’t think it was a bait-and-switch.
Nonetheless, your point is valid for services we rely on “for free”
1 Like
Very true. That’s why I am so dubious about relying any cloud service. Google map api is another example of what you are mentioning. One other way we have observed is for them is to get sold and go out of business which is not any better for us. The fundamental problem I have with those devices we own and can/should work without the cloud like the harmony though is why they should be pushing firmware instead of allowing for the customers to pull them. It is not a good trend I am observing from many companies. For me it started with the Ecobee. I was surprised these Harmony IR hubs were also getting FW pushed to them. Logitech are in their rights to disable or modify/patch anything in their firmware but clients should remain in control of implementations in their own homes and on the devices they purchased.
1 Like
Maybe we could have a grading system, Something like:
- Green: Using offical API
- Amber: Using unofficial Api
- Red: Reverse engineered comms
5 Likes
Really great idea, would be a big help in deciding on new hardware.
1 Like
since last night I cannot use my harmony hub anymore with HA.
I get only “Update for remote.harmony_hub fails” in my logs.
My harmony is on 206 and my HA is on 0.84.6
It was working the days before Christmas. Nothing changed in between.
Anyone facing the same issue?
1 Like
Tried this my self, Pushed out the custom Firmware on to the hub, HA running 84.6 . Hub is on the wifi, HA on the Lan, so discover fails, Tried to configure it via name + ip + port. but the custom component seems to fail there also …
Not sure if anybody else has had much luck.
This does not cause discovery failure.
Perhaps not no, but, either way … it’s failing for some rather odd reason …
Not sure… Works for me but I don’t use discovery
Strange, are you running the dev firmware and 84.6 ?