Right now if you add a device that is a home battery for example i need to add it manually and add the entities manually. Is it not possible to expand the device types? With the right entitities and setup so it shows as a home battery and also shows correct in the energy dashboard? Same with ev cars.
Do you have an example HA entity wherr the app could ‘see’ which entity/attribute is the right one?
I only know devices with multiple independent entities that are all standalone without any attribute marking them as import/export value - and you can’t use the entity name because every integration it doing it different.
Lawn mowers were requested in the past. Now I got some time to add a simple device. It has only the mower_state capability (mowinf, docked. paused, error) and the services to start/pause/dock after the picker got changed.
Anyone here who wants to check if it’s working? I have no device to test, so all is done in theory based on HA entity description.
Btw. The HA activity “returning” is not provided by the Homey capability, so that’s currently not used.
If mowers have additional states, it could make sense to add the entity state also as string capability to use this in flow conditions. But let’s see…
New test version 1.17.0:
- Added lawn mower device
Please test is it’s possible to add and control a HA lawn mower 
Can anyone talk me through how to simulate a When card for a Button press using this app please?
Athom have not exposed button presses on the official HA app for some ridiculous reason.
Look for the “When the state of [entity] has changed” card. Select your entity which will be named input_button together with the entity name.
i.e. “input_button.[entity name]”
Has anyone had the chance to test lawn mower device?
Just asking if it’s working in real live and if the app version is ok for live version
Hello @RonnyW
I have been using your application for some time and thank you again
On the other hand, recently I wanted to add all the devices on Alexa, everything goes up in Alexa except the shutters. The shutters seem to have the right capability and class. These components go back well from home assistant through HA Cloud and the home assistant skill.
Have you ever had this kind of problem?
Thanks
Hi, @RonnyW
Thanks for this amazing app, I use it a lot!
I think I may have found a small issue with how lock entities are handled when Home Assistant temporarily cannot update them.
I have 3 Tedee locks in Home Assistant, imported into Homey through the Home Assistant Community app. Two of those locks are connected to the same Tedee Bridge, while the third one uses another bridge.
Last night I suddenly got a huge amount of lock/unlock entries in the Homey Timeline for exactly those two locks on the same bridge, even though neither lock physically moved at any point.
The interesting part is that the timestamps in Homey match Tedee errors in my Home Assistant log almost exactly.
There are also several Error fetching tedee data: Error while communicating with the API messages.
The third Tedee lock, connected to another bridge, does not appear to show the same behaviour.
My suspicion is that the affected lock entity temporarily becomes unavailable or another non-locked state whenever communication with that Tedee Bridge fails.
Looking at the Home Assistant Community lock driver, I noticed this:
await this.setCapabilityValue("locked", data.state == "locked");
If I understand this correctly, this means that every state other than literally locked is translated to locked = false in Homey.
So states such as:
unavailable unknown locking unlocking
would all effectively become Unlocked in Homey.
Would it perhaps be safer for the app to only change the Homey capability for explicit states?
Something along the lines of:
if (data.state === "locked") { await this.setCapabilityValue("locked", true); } else if (data.state === "unlocked") { await this.setCapabilityValue("locked", false); }
…and simply retain the previous Homey state for unavailable, unknown, locking, etc.?
I realise the underlying Tedee communication errors are something I need to investigate separately, but ideally a temporary HA/API failure should not result in Homey reporting that a physically locked door has been unlocked?
Hi,
thanks for your hint. You are right, an undefined state should not toggle the Homey state. I fixed this and now only locked/unlocked is used.
New test version 1.17.2:
- Fixed lock state
