[APP][Pro] Shelly Wall Display Dashboard

[Andi]

Hi vixtor

No need to apologise

The next version catches errors per request and answers with a 500 instead of dying, plus a safety net for background tasks.

One thing that would confirm it, and you can check it yourself: open the app in the Homey app, go to its log, and look at the time the dashboard failed. If the app restarted, you’ll see its startup lines there — something like Capability subscriptions active for N devices and Dashboard läuft auf: http://…. If those appear around the time it broke, that was the cause and the fix applies to you. If there’s nothing at that time, the app kept running and the problem is on the display or network side — then I’d look at Wi-Fi after all.

Please install latest TEST version and let me know if this fixes your issue:

Shelly Wall Display Dashboard | Homey

[MarcoR]

With the latest beta firmware for the dashboard you get Matter support. With this you can add the relay as a Matter device in Homey and control it.

[GrayV8]

Hi @Andi I’ve recently installed the app and am utilising it very nicely on an old unused Samsung tablet, everything works very well except for one little issue I ran into today and couldn’t find a resolution for via searching.

I’m using the Advanced Virtual Devices and the numeric ones work just fine via your dashboard, but when I try to use an AVD text type, nothing is shown within the device. I have set up a Wind Direction avd “SSE”, “N”, “NW”, etc., data is shown in Homey for the avd quite fine, but on the dashboard nothing is shown in the device tile.

homey pro device shows ok:

but on dashboard:

I’ve restarted the service/app and fiddled a few things in both AVD device and dashboard, but no joy. Any help or things to try would be most appreciated, thanks in advance. Cheers, Gray.

[Andi]

Found it — thanks for the clear report, the screenshots made this quick.

It’s a genuine bug, not a configuration issue. When the dashboard shows a value from a capability it doesn’t know specifically, it was only accepting numbers. A text value like ESE was silently skipped, which is why the tile came up empty while Homey shows it fine.

The same check existed twice — once when building the tile and once when updating it live — so I’ve replaced both with one shared routine. Text capabilities now appear, and if your device uses a picklist, the tile shows the readable label rather than the internal id.

Two details: very long text is shortened to 20 characters rather than dropped, so a tile is never blank again; and I verified against 4000 random values that number formatting is completely unchanged, since that code was shared.

It’ll be in the next version - please test it: Shelly Wall Display Dashboard | Homey

Andi

[GrayV8]

Hi Andi, thanks for the fix to the text value, that’s now working exactly as you’d expect, and no impact to other fields / data / display as best as I can tell.

I do have a couple of other things I was hoping you could potentially look at as time allows.

First one is that if I use a Advanced VD on the dashboard, then there’s a slightly strange issue which occurs in some instances, and I’m not too sure if it’s my config of the AVD, or maybe a small defect. This is that the correct number of decimal places is not shown for some fields, but it’s hard to pin down which ones / why it doesn’t work, I can’t see the pattern. Here’s my example for Battery Energy:

you can see the “Battery Soc” has BE with 20.6, which is good, and this is the AVD config:

but on the display:

Note that i also just re-ordered the energy and SoC % so that % was first and bigger, but still 21 is shown with no dp. I realise this might be an issue with AVD and not your problem, so no stress.

The other thing I wanted to ask you about was if you have a good way of managing this situation: I control my AC zones in my house with homey and i have three zones which i can “force on”, “force off”, or “auto”, the latter which means the AC will check the temperatures in the zone and determine if the zone should be included or not. I’d really love to have a picker with “On”, “Off”, “Auto” per zone, which I’d see being selected / pressed and then run a flow to set my homey variable as such based on the selection. All of this would be perfect on the dashboard of course, but i cannot get any of your many ‘stock’ included devices to work for my situation.

I did install AVD as it has custom lists, so i thought i’d create on/off/auto and use the list, but the AVD devices don’t appear to work at all on your dashboard as buttons or selectable devices, like your built-in devices do, so that didn’t work. The closest I’ve gotten to something that works - but is really clunky - is to have the AVD showing the text value, and your 'Remote" ‘up/idle/down’ device run flows to set the AVD text based on button pushed:

in this case, ‘Stopped’ = “Auto”…but that’s pretty ugly.

Any thoughts on how this could be managed? Thanks for a great dashboard, btw, it’s really ‘clean’, easily configurable and looks great on my old AMOLED Samsung tablet:

[Andi]

Both of your points are in the next version: Shelly Wall Display Dashboard | Homey

Decimals. Tiles now follow the decimal places you configure on the capability, so your Battery Energy reads 20.6 kWh instead of 21. It’s treated as an upper limit rather than a fixed format, so a CO₂ value configured with 2 decimals still shows as 1119 ppm and not 1119.00.

The picker. Any capability you pick a value from — your Off / Auto / On per zone — is now operable. Tapping the tile opens the device’s own window, where each list appears as a row of buttons with the current one highlighted; tapping an option sets the capability immediately. No flow needed in between, but since it’s a normal capability change, a flow triggered by it still fires, so your “set the Homey variable” logic keeps working.

Sub-capabilities work too, so one AVD with mode.zone1, mode.zone2, mode.zone3 gives you one labelled row per zone. There’s no limit on how many lists a device has or how many options each one offers.

One thing I want to be upfront about: I first built this directly onto the tile, which is what you asked for. Testing it against a real installation showed it doesn’t survive contact with actual devices — a dehumidifier with two lists already had its second row cut in half at normal tile heights, and an air conditioner produced fourteen buttons on one tile. So the rows moved into the device window, one tap away. It’s the same pattern the app already uses for a colour light or a thermostat: the tile stays readable, the corner switch and sliders still work directly, and the full controls are behind a tap.

Thermostats and air conditioners get their extra lists inside the window they already have, below the mode buttons. Capabilities that already have their own controls — thermostat mode, alarm state, blind state, repeat, light mode — are untouched.

That should let you drop the up/idle/down Remote workaround. Let me know how it behaves with your zones.

[GrayV8]

@Andi I installed the beta version and it works just fine as you described the changes. I like the ‘tap to display’ option, that as you say is a sort-of standard in your app already, so it’s good to maintain that approach.

I tested out my various other real devices, VD, & AVD, and all displays and sliders/selectors work quite fine just as before. No issues noted from my testing, thanks very much.

I did come across some AVD configurations which don’t quite work, or not as potentially they could, but I’ll need to come back to this later to explain, after doing more testing with different settings within AVD. Ultimately I’m not 100% sure your intent with this app is to make it work perfectly with ALL virtual and Avd configuration / settings / values, so I don’t want to raise ‘issues’ just for the ‘fun of it’ Cheers again!

[GrayV8]

@Andi Hi again, I’ve done a bit of further testing to try to determine which aspects of AVDs are not quite working, and here’s an example below. Note that I’ve worked-around this slight lack of functionality, but if you feel like you want/can take a look to see what is going on, then it would certainly be appreciated, and would make the dashboard even more functional.

I have an actual / real Aircond and this is shown beautifully in the dashboard when I tap to adjust / view the settings:

What i would ultimately love to have for my AVD is the same or similar display but with three ‘current - target’ values with the adjuster +/- for target for each of my three zones. Potentially i’d also have the shown ‘off’ button as a modal off/on/auto, else simply the AVD custom lists, which work perfectly.

However, when I try to create the following AVD with low/high target temp and my three off/on’/auto custom lists, it ends up only showing the three lists:

My AVD config is:

i tried sorting the AVD fields in different orders, and also changed the low/high “Show as” to different things, but it never seems to display any sensor or slider or any other type when the text custom list is on the small window. Obviously these values and adjusters are shown quite happily within device lists in Homey itself.

Fyi my workaround is separate devices, e.g.:

where each of the temp. devices is a thermostat by itself with current & target. Works ok, but a bit convoluted.

Anyhow, if there’s a good reason why it doesn’t handle this situation, then just let me know, no stress

[Andi]

Could you do me one favour before I write this up properly? I’d like to confirm one detail rather than assume it.

Go to Homey Developer Tools , pick the AC Test AVD, and paste the details:

• the capability ids it lists (the raw names, e.g. target_temperature.low — not the friendly labels)
• the class and virtualClass fields

My working theory is that the AVD names those fields with a suffix after a dot, and that the dashboard only recognises capabilities by their exact name, which would explain both the missing thermostat view and the missing on/off switch. If the ids look different from what I expect, my explanation is wrong and I’d rather find that out now.

[GrayV8]

@Andi sure thing, no problem - let me know if you need anything else:

Those two screen grabs are the only fields / data shown for it, fyi.

Cheers, Gray.

[Andi]

Thanks, that changes my answer — and I’m glad I asked before posting the wrong explanation.

It isn’t your lists, and it isn’t a naming quirk I can be more tolerant about. Your temperature fields come through as target_temperature_min and target_temperature_max, which are their own capabilities, not variants of Homey’s target_temperature. The dashboard’s thermostat view is driven by target_temperature together with measure_temperature, and your AVD has neither. There’s also no current-temperature capability on it at all, so even in principle there’s nothing for a “current → target” line to read — the device carries two range numbers and three lists, nothing else.

So a thermostat view here would mean inventing one from capabilities that aren’t a thermostat, and guessing which of min/max is “the” target. I’d rather not: it would look right and be wrong half the time.

[GrayV8]

Whoops, so sorry, I inadvertently left the AC AVD with “max and min” target range fields when i was trying to get various options to behave. I’ve set the two fields “low” and “high” labels back to target temp fields in AVD:

[Andi]

Thanks for the correction — that does change the detail, though not the outcome.

With the fields set back, your capabilities come through as target_temperature.number1 and target_temperature.number2. The dashboard looks for a capability named exactly target_temperature, so the suffix is why it doesn’t recognise them. That part I could make tolerant.

I checked what you’d actually get if I did, and it isn’t good. There are two of them and nothing says which one is “the” target, so the dashboard would have to guess — the +/- buttons would quietly adjust one of your two numbers, with no indication which. And your device has no measure_temperature at all, so the “current” half of the thermostat view has nothing to read: you’d get a window showing “—” above an arbitrary one of Living Range Low and Living Range High. That looks broken rather than useful, so I’d rather not ship it.

The underlying thing is that a low/high range isn’t a thermostat in Homey’s terms. A thermostat is one current reading and one target. That’s exactly what your separate per-zone devices express, which is why they render properly — your workaround is the right model, not a compromise.

[GrayV8]

@Andi Yes, understood and fair enough that it’s not ‘clean’ to correct or make useable. Ultimately I don’t actually want/need a thermostat with current and target temps, that was just the closest device I could see possibly working like the real device does. I actually just need a pair of -/+ buttons which I could associate with either BLL vars or normal homey vars via flows when pushed to change the numeric value I designate via flow code. Then that number would change on the AVD on the dashboard immediately. Anyhow, if there’s no easy way to do this due to that not actually being represented as a proper device, then fair enough, and I’ll have to stick to the slightly expanded style currently. Thanks for looking into it though, much appreciated!