And an example of a dashboard using the Device Values widget that I have created Advanced Flows for each value Tile to colour code it with logic between green, yellow, orange, and red… and purple if it’s in an error condition… for example the Fridge temperature tile is blue between 0°C and 3°C, yellow between 3-5°C, orange between 5-7°C and red above 7°C… and if the temperature reading is negative it turns purple. I have created a similar Advanced Flow for the Freezer temperature tile, just with different temperatures.
Having the colours customisable in Flows, rather than just in the widget settings, makes them far more customisable for so many different devices/applications.
My Fridge Freezer is plugged into a smart plug with energy monitoring, so the tile next to the temperatures turns green to show its compressor is running and actively cooling when over 20W, and turns to default grey when below 20W. The screen was taken just before the compressor kicked on, hence the colour of the tiles being orange, orange, grey.
You can do this with the Lists app, but that is restricted to the iOS/Android app dashboards. It would be nice if this could be added to the web WidgetKeeper Dashboards (either displaying the Lists app list device, or a completely new custom list, but that would be a bit of a duplication of app functionality)
I hope the number of posts here isn’t getting you down. I think it’s a measure of the enthusiam your app is generating. For my part I have transformed the home page of my phone app.
That being said, I have an issue and a suggestion…
I use Switchbot curtain motors. For a reason known only to Switchbot, independent curtain motors use position 0% for open but connected curtains (that open and close as one device) use position 0% for closed! There is an advanced setting ‘Invert open / close position’ that drives device setting invertPosition but that doesn’t seem to change anything in Homey. I don’t know if the setting comes from the Switchbot app or the Homey driver. If you observed the setting, however, it would correct the appearance of your widget which currently shows connected Switchbot curtains as closed when they are open. It would also help if you could use a little tolerance of a few percent when showing ‘fully open’ or ‘fully closed’ - the Switchbot app does this.
I’m going to guess that curtains/blinds are going to be a pain for you!
I have an e-bike (Orbea, so not a knock-off manufacturer). I have a flow that switches the charger on, waits three hours, and turns the timer off. It would be handy to be able to change the background colour of a flow button from a within a flow so I can see at a glance if the bike is charging, or not. I would drive that from the device state so - if the smart plug disconnects (it’s outside the house, so not completely reliable) I can see if it’s charging longer than I want. That’s a specific use case, but I suspect the ability to change the background colour of a flow button from a flow would have many uses.
All power to your elbow as the saying goes.
Andy
Edit: I forgot to say that capability windowcoverings_closed shows the connected curtains are closed when they are open regardless of the invertPosition setting.
I reached out to Athom on the positon and states Homey reports of the SwitchBot curtain drivers, as there seem to be some inconsistencies (see this post up in this topic). They are currently investigating my observations.
Keep in mind that 100% is the default value Homey uses for fully opened and 0% for fully closed. SwitchBot works the other way around: 100% is fully closed. The ‘invert open/close position’ inverts that (at least in my case): 100% is treated as fully opened. So it should invert the meaning of the position value. However not all icons/states change consistently (that is part of my report to Athom).
I assume Widgetkeeper receives the open/close/position info from Homey and uses that as a basis. If that info or some parts of it is incorrect then that will result in unexpected behavior. So I think first Athom needs to ensure that curtain position and states are handled consistently in order for derived widgets to work properly.
YES, well said that man… this app and it’s widgets have transformed my mobile app home page, and also made my Shelly Wall Display XL useful and responsive again with the web widget. There is no doubt in my mind that this app has been a game changer for Homey smart home standing ovation good sir
I suspect this is an ongoing issue for all manufacturers since position n% is meaningless in itself. Widgetkeeper can isolate itself from the issue if invertPosition is a setting introduced by the Homey driver (rather than being Switchbot-specific). Following invertPosition will mean the widget can work correctly (for curtains at least), regardless.
So that is what Homey expects. Additionally. it provides the ‘invert’ option if devices report the position in the opposite manner, so that it is in line again with what Homey expects.
Having messed around with the ‘invert’ setting, I closed the connected curtains this evening and now everything is showing correctly in Widgetkeeper. It looks like an open/close event is needed to activate the invert setting. Right now it’s set to off so I guess it was on when I saw the issue. Sorry to have started a hare running unnecessarily.
Request for tolerance when showing fully open/closed still applies, though.
.
Never heard that!
