I already added the power sensor to switch device (like it’s done fro lights) for the next test version.
If a switch.entityname has a sensor.entityname_power, it’s used automatically. If the sensor doesn’t use the naming, you can set it in device settings:
Some other features like mdi icon library update will added, too.
I’ll give an update if the test version is online.
That’s brilliant! Talk about fast!
I have a few switches measuring Volt and Ampere if you ever feel like adding that ability too.
(Like Zigbee switch “TS011F” sold as Neo Coolcam zigbee using “sensor.entityname_rms_current” and “sensor.entityname_rms_voltage”,
as well as Z-wave socket from Aeotec with “sensor.entityname_electric_consumption_v” and "sensor.entityname_electric_consumption_a")
I don’t think that this will be added. It’s more a sensor thing for insights. So better to collect these additionyally sensors in a compound device. The question is: how often do you look at these values?
The energy measure is added to light/switch to be able to see the consumption in the energy summation. There it’s better to have the device itself with its energy data as capability.
The switch device is made to import the switch domain as device, but not all direct/indirect sensors.
I hope that’s ok for you 
Edit: I’m thinking about changing the compound device class to “socket” instead of sensor. Would offer to use the “plugged in” option, but would be a bit weird in pair dialog.
You know what? i’ll probably NEVER look at them 
it’s probably just me having too much of a pokémon-gotta-catch-em-all-mentality, like if they exist i “need” them but will probably NEVER use them 
So, I think you might be right!
Off the top of my head I can’t see any downside to changing Compound to “socket” for me personally… the only thing that I can think of is IF i’d like to collect all those sensors, i’d probably never look at, in one compund device to use in like a monitor-flow to see if anything out of the ordinary occurs and then warn me, it might be problematic if Homey MUST have an onoff capability tied to that compund? And if that is the case (but i’m not sure?) there might be some breaking changes to peoples devices after update? At least that whas my thought when I suggested the Compund Switch - to rather add Devices than change existing ones.
I was gonna try it out myself and forked the app, but haven’t used CLI for two years and it refuses to even run apps and throws errors at me so I gave up… Just as well probably since I suck at javascript
Ok, let me try the compound-socket version. I don’t think a on/off is needed for.
and yeah, if you have a lot of data you want more
But with a compound you can collect the sensors and with flows you can check for peaks if needed.
Thx Ronny, had no idea that the colouring was a default use of Homey. Does the same apply for the main tile (expected: a/c on=coloured tile a/c off= tile greyed, but the tile appears to suggest an active state continuously. That would IMHO an improvement as well.
Peter
Hi,
the tile is only showing the same as the device detail view (colored blue or orange).
The tile won’t get disabled. That’s only possible for on/off capabilities (switches). A thermostat has a mode that can operate independent. And even if you set a mode it’s not sure if the device is on (heating/cooling) or off (doing nothing).
The climate domain has an attribute hvac_action, that will show the current state in the sensor view (if it’s provided by the HA integration).
See the definition: Climate Entity | Home Assistant Developer Docs
But that would not really fit to the tile state.
The tile could represent the climate mode. If mode=off (like a switch that is off) the tile could be inactive/grey and on other modes (AC is switched on) the tile will be active. But it won’t represent the current AC state.
Edit: I will add the tile state dependent on selected mode (so a static state like a light/switch).
New test version: 1.1.0
Small hint for window covering device:
It’s base device that offers the possibility to select a “virtual” cover type (like it’s possible for socket device type) - but only in mobile app.
Hi Ronny,
Below are my test findings:
The tile enabled/disabled works like a charm. I clicked Off (“uit”) in the webbrowser and the tile is disabled almost immediately. However, the detailed screen is not updated, “Heat” (Warmte) is still displayed as the selected mode
I doubt if this is browser related, because the last detail screen (log) is updated.
Furthermore, I’m also not aware if the detail screen of this device should be disabled/transparent if the device is disabled. This could be a feature, assumed this can be controlled by the app.
The Dutch translations can be improved.
Log screen: “Op” should be “Aangezet” and “Uit” should be “Uitgezet”. The last one is not necessary but is more consistent with log items of other devices.
The mode of operation screen should be (only changes are displayed):
Warmte → Verwarmen
Koel → Koelen
Warmte/Koel → Auto (verwarmen/koelen)
Droog/vochtigheid → Ontvochtigen
Alleen fans → Ventileren
Flow cards and tags
Schommelen modus gewijzigd → possibly change into AC modus gewijzigd
This card confuses me. The “modus” setting in this card is displayed as “vertical” but the variables in the next card are referring to the device mode of operation (heating, cooling. etc.).
Luchtstroom gewijzigd
As there is a card “airflow changed” (Luchtstroom gewijzigd), this is more consistent with the swing (schommelen) mode of the previous card.
.
I have to test the available variables (Op, Uit, Verticaal, Horizontaal, Beide), but “Op” definitely seems a wrong translation.
FYI, the available swing modes in my device are: Up/Down, Left/Right, 3D. Up/down includes 6 fixed positions and a swing modus.
Left/right includes 8 fixed positions and a swing modus.
Wijzig naar Luchtstroom → change into Wijzig luchtstroom
The info text had typing/spelling errors: change into “De lijst wordt geleverd door de AC-unit of de HA-integratie.”
Wijzig fan modus → change into Stel fan modus in
Consistency: Change the first letter into a capital
Overschakelen naar vooraf ingestelde modus
The info text has translation/spelling errors, this should be: “De lijst wordt door de AC-unit of door de HA-integratie geladen.”
Peter
Works like a charm! Good job!
One thing I discovered was that one of my Plugs has a “child lock”, this was favored as the devices on/off switch before it’s actual on/off switch. Easy to remedy by hiding that entity in HA and search again to get the right switch.
Adding the watt sensor from settings works great!
The only thing I’d love to see is the kWh-option as well 
kWh option is there you need a home assistant name that ends in _power this plugin works
Then that’s the explanation. The only plug i’ve tried adding with the new update has its entity named “sensor.name_summation_delivered” for som weird reason! I’ll try to override the entity ID in HA then 
Yeah, so either we’re talking about different things or i’m totally missing something. All my entities measuring “kWh” is named things like “sensor.name_electric_consumption_kwh”. While everything measuring Watt is named “sensor.name_power”. And changing the names on these entities does not make them show up with the new feature of the switch as far as I can see with the ones i’ve tried them on. If you’ve managed to add “kWh” in the advanced settings-tab of the updated switch i’d be really happy to know how you’ve done it
So, this kinda happaned again
During this time I could connect to HA using browser and phone app and control everything. So something is up. The first time it happened I just added one device, but this time I was adding and removing things so it may well be because of me torturing the app this time
I’m not so sure this is worth for you putting any effort in to investiganting unless it persists and others notice it as well, just thought you should know if others experience similar issues. The app seems really stable when it’s just being used for day to day automation stuff so far!
Hm, sound as if the wewbsocket connection to HA was interrupted somehow.
If that happends again, please open the repair view of a device and check the app log. You can also create a diagnostics report for the app. But in the app log you should already see some errors.
I hope that points us the right direction to investigate. Thanks.
And as fast solution you can push the reconnect button in device settings. This will hopefully reconnect to HA if it’s broken.
I think you mix some things up.
The power addition for the device is meant for getting current power measure (Watt) data into the homey device. It’s used to add the device into Homey power consumption (the energy overview in Homey app).
All other sensors provided by the switch are just statistics.
The HA switch entity has only the on/off state, nothing else. The sensors are different for all integrations. There is no standard like used in Homey. Every integration can do whatever it wants. That makes it hard to find a common solution between HA and Homey.
That’s why I decided to add the power entity for Homey energy. But other sensors should be includes as single sensor device or better as compound.
Don’t take HA devices to serious. At the end it’s only a collection of entities, you have to add one by one to a dashboard.
I want add a device setting for compound device to select the device class (sensor/socket…). So this could be another possibility to add your plug as compound including all sensors.
That’s controlled by the GUI/App.
And the mode list could hang if the app restarted while it’s opened (or something like this). Sometimes it needs to close the detail view ans open again to get instant reaction.
