Martin_

Hello. I have asked this in the Shelly wall display thread and got an answer that some control option where rejected, but after using the display now for some months i think that the current implementation is not the best solution. I don't use the Wall display at all for RGBW control, I'm forced to use the app, and that is a bit sad, as the display is great and with small tweaks could be better. Colors: The thing with color selection is that every led stripe is different, meaning the output from the colors R G B W is different, so if i press the orange color on the color wheel for example, this is the color i get i reality in the stairs (almost white). (Red selected in the image, but orange is selected below) The actual color i want is down in the stairs, that is "orange" as in the color wheel, the colors get shifted in the photo. White channel is turned off. So the result is that i always have to use the app, so the wall display becomes unusable for controlling the color and light with the RGBW. Also, pressing for example RED, doesn't turn off the white channel, so the result is not RED, unless i also turn off the white. Sliders: Pressing the sliders results in the RGBW turns on / off instead of shifting to the pressed level on the slider. Updates to the RGBW control: Please implement option(s) to control RGBW differently, for me i could use different ways. The default can still be what is today, but with options to change to something else for better control. Here are 4 things that would be great options so we don't have to use the app: 1. Option to show favourite colors that are saved in the app and save colors directly in the display. 2. Option to show separate sliders for each color + saving the current color to favourites. 3. Option to show a color wheel, the way we could at least "tune" the colors, even though they won't be 100% to the wheel, but they are not correct now anyway 🙂 4. Option to select colors (with RGBW numbers) for all (or some) of the "dots" in the current implementation, eg long press on a color dot brings up an input with RGBW number, so a favourite can be saved. Option 1+3. Option 2 (but implement favourites as well, as in image above).

Hi! Could we get a new setting in the next firmware update to the Shelly Dimmer 2 to be able to set "Maximum Brightness" value? Often the first 10% does basically nothing for the light intensity going from 100% -> 90%, so this would be a great addition to be able to fine tune the slider. It's also great for "syncing" different light sources to match, or if you don't want to use all the range of a specific light (decoration) and you only need a max of 50% but want to use 0-100% of the slider. For example, going from 100 to 90% uses 10% of the slider in this case, but the actual light does not differ, and the power change is less then 1 W.

@Heinz Hello! Yes, but not changing, just adding the possibility to add virtual components from (for example) a 1PM mini Gen3. I want to be able to add virtual components (labels, buttons, enums, sliders, images etc ) to the Wall display (with the + sign) from other devices. Now we can only add VC if they are made in the Wall display, and they are limited to buttons without scripting. With that possibility we could give the wall display so many great possibilities with feedback! If we could get scripting and and the same virtual components options as on a 1PMmini Gen3 on the wall display that would be even better 🥳 A personal great function for me (if this could be possible) is to control my Sonos system (Sonos is on a different vlan) so i can't use the plugin. Mockup image of what would be nice (slider would probably have to be vertical similar to WD), but you get the idea. Here is a image box and a slider.

That sounds fun! Perhaps you can give more hints? 🤩

Hello, perhaps this is in the roadmap already? I would love to be able to add buttons, sliders, enums to the WD (from other Shelly devices, or make it possible to do VC in the Walldisplay through browser), this would be a great addition!

Hi everyone. Sometimes the best way to learn is to do, so i made this Shelly script that uses 3 virtual components with Sonos information from HA. I get the current song, album art and can control the volume with a slider. The information path is Shelly -> HA -> Sonos. I made a separate script for setting the volume (It can be 1 script, but i liked to have them separate) We could implement more controls to be able to control Sonos from the Shelly app. We could also get HA to control the components (so no polling is needed), but i wanted to do it like this to learn scripting. I would love to be able to add the virtual component group to the dashboard, Shelly is this a thing that could be implemented? App view of final result: You need 3 virtual components (and put them in a group) - 2 with text and label. - 1 with number and slider. Device: Code: The tabbing gets strange when posting the code, sorry about that. Code for getting song, album art and current volume: // CONFIG START let CONFIG = { homeAssistantUrl: 'http://10.0.0.1:8123', // URL of your Home Assistant instance accessToken: 'YOUR HA TOKEN', // Your long-lived access token sonosEntityId: 'media_player.sonos', // Entity ID of your Sonos speaker checkInterval: 10000, // Check every 10 seconds debug: false, // Show debug info debug_error: true, // Show debug error info vd_textID: 200, // VD text id to hold the current song vd_textImageID: 202, // VD text id to hold the Album art volumeSliderID: 200, // VD of the virtual slider to hold the volume album_undefined_icon: 'https://www.shareicon.net/data/128x128/2015/08/12/83951_info_512x512.png' //Change to what you like }; // Debug log function function log(log_info) { if (CONFIG.debug) { print(log_info) }; }; //Function log end // Error log function function log_e(log_error) { if (CONFIG.debug_error) { print("ERROR: " + log_error) }; }; //Function log error end function GetSonosData() { print("Starting to fetch Sonos info from Home Assistant..."); // Debug message Timer.set(CONFIG.checkInterval, true, function () { Shelly.call( "http.request", { method: "GET", url: CONFIG.homeAssistantUrl + '/api/states/' + CONFIG.sonosEntityId, // Home Assistant API endpoint headers: { "Authorization": "Bearer " + CONFIG.accessToken, // Bearer token for authentication "Content-Type": "application/json" }, timeout: 5 // Set a timeout for the request }, function (res, error_code, error_message, ud) { if (error_code === 0) { try { let status = JSON.parse(res.body); // Parse the JSON response // Create the album art URL let albumArtImage = status.attributes.entity_picture; let albumArtUrl = CONFIG.homeAssistantUrl + albumArtImage; // Get current track information let currentTrack = status.attributes.media_title; // Get song let currentArtist = status.attributes.media_artist; // Get artist // Fetch the volume level let volumeLevel = status.attributes.volume_level; // Float between 0 and 1 // Update Album art if (typeof albumArtImage !== "undefined") { // Display the album art Shelly.call("Text.Set", { id: CONFIG.vd_textImageID, // ID of the virtual text component value: albumArtUrl // Text to display (link to image) }); // Print the current album art URL information log("Current album art URL: " + albumArtUrl); } else { // Update the virtual text component to indicate no album art Shelly.call("Text.Set", { id: CONFIG.vd_textImageID, value: CONFIG.album_undefined_icon }); log("No album art currently available, setting default image"); }; // End Update album art IF // Update track info if (currentTrack) { // Create the text let displayText = "Song: " + currentTrack + " by " + currentArtist; // Update the virtual text component Shelly.call("Text.Set", { id: CONFIG.vd_textID, // ID of the virtual text component value: displayText // Text to display }); // Print the current track information log("Current track info: " + displayText); } else { // Update the virtual text component to indicate no track is playing Shelly.call("Text.Set", { id: CONFIG.vd_textID, value: "No track is currently playing." }); log("No track is currently playing."); } // end of currentTrack IF // Update volume level if (volumeLevel) { // Update the virtual slider with the current volume Shelly.call("Number.Set", { id: CONFIG.volumeSliderID, // ID of the virtual slider component value: volumeLevel * 100 // Convert to percentage (0-100) }); // Print the current album art URL information log("Current album art URL:" + albumArtUrl); } else { // Update the virtual slider with no volume Shelly.call("Number.Set", { id: CONFIG.volumeSliderID, // ID of the virtual slider component value: 0 // Convert to percentage (0-100) }); log("No volume value received."); }; // End Update volume level I // Catch potential error } catch (e) { // Check JSON reply for errors log_e("Error parsing JSON: " + e.message); // Log for error debugging log_e("Response body: " + res.body); // Log for error debugging } } else { log_e("", "Error fetching Sonos info: " + error_message + " (Code: " + error_code + ")"); } // End of if error_code 0 }, // End of response func null); // End of Shelly.call http request }, null); // End of Timer.set }; // End of CheckSonosCurrentSong function GetSonosData(); Code for setting the volume: // CONFIG START let CONFIG = { homeAssistantUrl: 'http://10.0.0.1:8123', // URL of your Home Assistant instance accessToken: 'YOUR HA TOKEN', // Your long-lived access token sonosEntityId: 'media_player.sonos', // Entity ID of your Sonos speaker debug: false, // Show debug info debug_error: true, // Show debug error info volumeSliderID: "number:200" // ID of the virtual slider to hold the volume }; // Debug log function function log(log_info) { if (CONFIG.debug) { print(log_info) }; }; //Function log end // Error log function function log_e(log_error) { if (CONFIG.debug_error) { print("ERROR: " + log_error) }; }; //Function log error end // Function to set the volume in Home Assistant function SetSonosVolume(volume) { log("Setting Sonos volume to: " + volume); // Debug message Shelly.call( "http.request", { method: "POST", url: CONFIG.homeAssistantUrl + '/api/services/media_player/volume_set', // Home Assistant API endpoint to set volume headers: { "Authorization": "Bearer " + CONFIG.accessToken, // Bearer token for authentication "Content-Type": "application/json" }, body: JSON.stringify({ entity_id: CONFIG.sonosEntityId, // Entity ID of the Sonos speaker volume_level: volume / 100 // Convert percentage (0-100) to float (0-1) }), timeout: 5 // Set a timeout for the request }, function (res, error_code, error_message, ud) { if (error_code === 0) { log("Volume set successfully."); } else { log_e("Error setting Sonos volume: " + error_message + " (Code: " + error_code + ")"); } }, // End volume response check null ); // End Shelly.call }; // End SetSonosVolume function function onEvent(event_data) { log("Event data: " + JSON.stringify(event_data)); // Shows event data let component = event_data.component; // Get event data name let componet_ID = event_data.delta.id; // Get event data ID let componet_Value = event_data.delta.value; // Get event data Value let info = event_data.info; // Get event data info if (component === CONFIG.volumeSliderID) { // Check for inpout from slider with type and slider ID log("VD information ID: " + componet_ID + " Volume: " + componet_Value) if (event_data.delta.value === 0) { log("Volume is off"); SetSonosVolume(event_data.delta.value); } else if (event_data.delta.value >= 0) { log("Volume is on"); SetSonosVolume(event_data.delta.value) } }; // End IF component if (info) { //Check for false info log_e("Error in received event data") log_e(JSON.stringify(event_data)); return; }; // End IF check for bad data }; // End of onEvent function print("Started Statushandler for Sonos VD Volume Slider"); // Create status hadler Shelly.addStatusHandler(onEvent);

Hello. Is there a reason the components of the WD are different to (for example) a Mini1PMG3? Is it in the roadmap to implement the same components in the WD as the Mini1PMG3? I would love to be able to add buttons, sliders, enums to the WD as VD buttons, this would be a great addition! Or, add the option to add other devices (ex Mini1PMG3) VD components to the WD, that would also work.

Here is a calculation for 4, 10 and 16A MCB fuses showing maximum Ik1 short circuit current for each circuit (0,3kA), they are all the same (except for W004) We can see that the biggest impact on maximum short circuit current is the area (mm2) of the cable (compare calculation W001 and W004, same fuse different cable 1,5mm2 vs 2,5mm2) As the cable has less resistance the current will be higher when there is a short. But, as you can see, for short circuit protection only, it doesn't matter if you have a 4A, 10A or 16A MCB fuse as the fuse will blow at the same time (0,1 s) so the current will be the same.

@thgoebel @tvbshelly @TNa Hello. I small update regarding the fuse situation. I have now looked into this regarding the fuse of the device with my electrical calculation software supplier. I don't know how much you know about fuses (so i will explain it) but there are 2 different things to consider if you have a fuse. 1. Over current = Limits the current output so we don't connect too many things on a fuse. 2. Short circuit = Limits the current when there is a direct short or fault. 1. Over current: If we consider point 1, then this would protect the internal relay of the WD from over current, ex connecting a 10A (2300W) radiator to the circuit, the internal relay is not made for this load. 2. Short circuit: This is if we get a short (after the relay of the WD) Now, this is where the mind bending begins, it doesn't matter if you have a 6A or 10A fuse for the WD, the Ik1 (short circuit current) will be the same for both fuses! It depends on the cable impedance (lets say 1,5mm2 cable) we will get the same trigger time (0.1 s) from the 6A MCB as the 10A MCB, and so the short circuit current going through the WD will be the same! So to summarise: The 5A in the WD specification is for the internal relay only. If we limit this load "1" (to under 5A) then there is no problem having a 10A fuse for the display, as the "2" short circuit current will be the same. Therefore: Shelly could update their specification and make it clear that the maximum load (1) on the internal relay is 5A (over current protection). And, for short circuit protection (2), that can be 10A (or even 16A MCB) = This enables all installations. Perhaps this would cause confusion, but i don't see it, as almost all their other devices have the same situation. Ex Shelly 1PM Mini Gen3, maximum switch current is 8A but the fuse is 10A.

Hi JayKay. If you get into (perhaps you already are) IoT, there is almost no "perfect" solution for all things in the house. While i understand your points, perhaps sometimes the idea of the "perfect" solution might be a good enough one. Perhaps depending on your usage case of the WD, this might not be an issue at all If you only change your thermostat to control heating / cooling and you wanted a display, then yes, perhaps it's not "perfect" for your usage case (or perhaps it is) see below. But, if you are going to use any other functions of the WD, then you need WiFi and / or internet. I understand your point, but, BT fails, hardware fails, your heating systems can fail, nothing is perfect. The only thing that might not switch automatically (while the Wifi is down temporarily) is between heating and cooling in spring / autumn, and if the Wifi is down you will notice it directly (i guess you have many things that are on Wifi). You make a script that checks if the switch is made, that always polls the thermostats. That would (in my opinion) be more robust than a standard heating system, as Shelly can send a message if something is not working right. You can also now monitor all thermostats (and states) and zones, check that all the devices are working etc and gain alarm functions if it's too hot / cold for different automations and alarms. So, what is fails safe and robust i guess is the question. Yes, Wifi can go down temporarily, but you will gain monitoring that you did not have before. Add to that all the things you can do with the WD and compare it to a "dumb" thermostat, i think it's a no brainer to get it. This is only my opinion, and i have advocated to use physical buttons (connected to relays / dimmer etc) for lights etc always (as backup if Wifi goes down) but in the last build I'm doing now, I'm moving away from it. I don't touch my switches in the house any more, everything is mobile, or automatic and i have around 70 IoT devices (Lights, Heating, Cooling, Ventilation, Media, Audio all on WiFi). I have had the power go out more times then the WiFi goes out, so if I'm to guess, the future is a WD in the room and no more pulling cables all over the place to all lights and functions. It just makes sense these days, (in a home enviroment) Wifi is now so essential for everything. For critical components, then sure there are exceptions in the way to implement that control 🙂 In short, go for it 😄

Sorry, i will try to be more clear, do ask if I'm not! Yes, the display always works as a thermostat, and you can change the heating / cooling directly in WD in settings (if everything fails) Not with SW input, it was confirmed above, but this is how i would do it in your case: This is your current connection to the heating system as I understand it, correct? 1. Add a shelly device with a input (ex 1PM mini Gen 3) and connect the control output from your heating system to the input of that device as below: 2. Make actions in the 1PM mini that switches your thermostats from cooling to heating when input is on or off with this command: Heating: http://IP_OF_WD/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:heating} Cooling: http://IP_OF_WD/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:cooling} You can add 5 thermostats per action, if you have more, add more actions. Done!

Thank you for your prompt reply, that explains a lot 🙂 @Dimitar Buckoff i would love this feature! 🥳 It could be used to control different things, lights etc. Often room thermostats have a light switch below it, so adding a "free" input in the WD could make the switch below a smart switch with multiple actions (1, 2,3 long and short press), i have this exact scenario.

Hi @Olsche Im trying to change the mode from heating to cooling from the input of the WD, but i can't get it to work. Perhaps you can help me? This command works only from virtual buttons and "Screen swipe and Screen touch": http://IP_OF_WD/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:cooling} But it does not work if i try to change the mode locally or if use actions in "input:0" and use trigger "Input toggle". http://127.0.0.1/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:cooling} I have made actions in "input:0" and i see that i get key events from debug (when using input SW), but no webhooks are sent. What am i missing here?

Could you add a Shelly input (relay or similar) in the cooling controller and switch the modes with actions as an alternative perhaps? http://IP_OF_WD/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:heating} http://IP_OF_WD/rpc/Thermostat.SetConfig?config={%22id%22:0,%22type%22:cooling}

Hi @oliverb, i also use webhooks with HA and don't need POST (its built in the virtual button) This is how i do it: For example: http://192.168.1.10:8123/api/webhook/-d_FQkvfErM_BBFY0u6ATMycZ