[APP][Pro] Home Assistant - Community App

Hi,
basically all (or most) basic HA entities (or domains) are added ad device that need special interaction like reading attributes and convert to Homey capabilities or use HA services to act with the HA device.

All devices are based an a domain and it’s entity like sensor switch light…
So you can

  • add one or all entities as device
  • add one entity as device (switch) and add all device sensors in device settings
  • add one entity as device and add several entities in repair view
  • start wit custom device and add what you want.
3 Likes

@RonnyW Wow! This app is amazing and gives me endless possibilities. Thank you very much! I have a few questions:

  1. For the compound device; is there an options to create a thermostat with (dynamic) min max?

  2. For the custom device; is there also an options to create a thermostat with (dynamic) min max? And is there a way to use an entity attribute as value?

  3. For the thermostat device; Is there a way to dynamically change/update the min max?

Thank again!

Compounds are used to combine “simple” entities like sensors, buttons, switches.
A thermostat is part od the climate domain in HA and needs some special data and service handling to sync with a Homey device. That’s why thermostats must be added as Climate device.

Same as compound. Only “simple” and generic domains are used.

Adding the thermostat as climate device is the only way. On adding, the thermostat definition from HA is used (min/max/steps). They are not changeable afterwards. But you can update/reset this device via repair function. This way all capabilities are removed and re-added again using current HA entity data. If min/max has changed, the new settings will be imported into the device. But all existing entities will be removed (if you added some custom entities before).

Btw…why do you need dynamic min/max values? Normally these values are predefined by the (hardware) thermostat.

This new functionality easily solved my Garage Gate issues with multiple sensors. Just removed unwanted battery sensor and teperature sensor for each gate. Thanks a lot!

New here, but enjoying your work a lot!
I noticed that when adding a (Hue motion) sensor from HA Community, I get only the motion and not the temperature and the luminance. When doing same from the HA Official app, I get a device with all three capabilities.

Custom device (which feels somewhat similar to building an AVD @Arie_J_Godschalk) helps me to add all three into one device.

If it seems a default for the HA Official app (which is barebones compared to Community), could you perhaps auto combine these capabilities in one device? It would save me having to build 20 Custom devices :slight_smile:

Hi,

I know there are houndreds of posts but it was already explained in several ways.
Here is the short version for you :wink:

  • The basic structure comes from the “old” developer/app and was based on possibilities of HAs websocket connection.
  • It’s domain based (switch/sensor/light…), so for mostly all main HA domains there is a device that manages the data conversion and HA updates via services.
  • You select the entity you want to add and you get a specific device with capabilities, flows etc. like a climate device. The device offers specific flow trigger, conditions and actions for this main entity based on the used capabilities.
  • Then you can add device sensors/switches/buttons in device settings or add them manually (if you only need some) in repair view.

So you can add additionally sensor in a second step. But as profit you get a device with all possibilities offered by the uses capabilities like flow triggers, actions, measurements etc.
It’s another approach that offers more device specific functionality and much more customizability instead of a limited generic device adding at the expense of simplicity.

So I think adding device sensors yould be the easiest way for you. Here is an exaple:

1 Like

Amazing! Apologies for not catching on fast enough, but this is great.
Offloading HA Official right now. :sweat_smile:

Question: when renaming a HUE motion sensor, how long does it take to be reflected in the device or do I need to execute something?

Entity updates will be pushed directly to Homey, so you will see it instantly in pair view.
But you can also change the sensors (capability title) afterwards in repair view.

Indeed HA updates the name as soon as I update the name in the Hue app. But the device name in Homey does not update.

With Pair View I guess you mean when setting up a new device.
After the device is set up in Homey, I checked the Repair View on it to align the device name in Homey with the device name in HA, but Update/reset won’t update the device name.

What am I doing wrong?

I think you misunderstood the meaning of device name and capability title.

The device name is set on adding and can be changed in device settings like every other Homey device.
The capability titles can be updatedbin repair view.
For main capabilities, the title of Homey capabilities are used - and don’t need to be changed.
If you added further sensors (with button “Add entity” or in device settings/add device sensors), you can update their capability title in the repair view (your screenshot) using button “Change entity”.

Right, thanks. But I want the device name to change when it is changed in HUE like the HA device name changes when the device is renamed in HUE.

No, that’s not the way how Homey devices are used.
Every device in Homey gets its name while pairing that can be easily be changed in device settings. All devices are working this way and I won’t break this Homey logic.

A compromise would be to update the device name when using the repait function “Update device” when it’s refreshed with current HA data. But that are still more clicks than just changing the name in device settings.

Thanks. No need to change accepted practice.
However, without HA and purely working with devices from the Hue app in Homey, the devices change name when changed in Hue.

Equally, when the name of the device is changed in Homey, then the change is also seen in the Hue app.

There seems to be a way, no?

Which Hue app is it? The ‘without the bridge’ version?
Then it’s one app doing non standard things.

On one side it’s easier for you. But on the other side dealing with several Hubs, services (Hue, HA, Alexa) can be messy with automatic renaming. In Alexa I rename devices for easier voice commands but won’t get synced this name back to Homey because there I want to have more detailled names.
So it depends on your personal usage.

I work through Bridges only.
image

I have checked again: it seems one-way only, but still nice.
So I can change device name in Homey and then both Hue (and HA) receive the new name.
When I change the name in Hue, then only HA receives the new name.

It is fine that way.

I have a partial date/time string delivered from a sensor defined in a compound device. The format delivered is like this: 04-14 18:50
Is there an easy way to add current year to this partial date/time string while converting it to locale format with capabilitiesConverter?

capabilitiesConverters:
measure_generic.last:
from: “(state) => { return new Date(state).toLocaleString(‘no-NO’, {hour12s: false, hour: ‘2-digit’, minute: ‘2-digit’, day: ‘2-digit’, month: ‘2-digit’, year: ‘numeric’ }); }”

The result of this converter is that year for some reason is set to 2001. I want it to be current year.

I also wonder if it is possible to add new/custom icons for sensors within a compound device or if only predefined icons for defined sensors in Homey are used?

Yes, it is. With common JavaScript:
Here is the beginning of the converter. Just add new Date().getFullYear()+'-'+ in front of “value”:

(value) => { return new Date(new Date().getFullYear()+'-'+value).toLocaleString(...

This addes the current year “2023-” to your date string

For capabilities the images must be added to the app. That’s why only the the common icon based in Homey capabilities are available.

Workes like a charm.
I will have a look in the JavaScript command documentation next time.

Thanks…