HA SwitchPlate HASPone: DIY In-Wall Touchscreen Home Assistant Controller

I just love it when I come here and find something like this. Superb.

I fixed the typo (thanks for that catch!) but I can’t for the life of me figure out why the heck GitHub thinks one STL can be downloaded but the other can’t :frowning: If you download the whole repo from the main page it will zip up everything for you so you can still grab the file but… I’ll need to look into that today.

Sounds like a common problem with how GitHub interprets these files. No real resolution on my side to create a download link, but you can right-click on the “Raw” button, select Save As, and you’ll get the file.

yep I was able to get the file through the zip of the whole repo. Thanks!

EDIT: I noticed another issue and have run into this previously. In the clock animation you have:
"\"{{now().strftime('%A')|center(20)}}\\r{{now().strftime('%B %-d')|center(20)}}\""

I get the current day of the week right aligned on the top row and the month/date is missing. I’ve done some reading on the issue and it has something to do with \r vs \n on the display and which one it actually interprets properly. I’m wondering if my display might be on an older firmware?

Whoops - bad version control on my part. That was an experiment to center-pad text using Python before handing the string over to the Nextion which didn’t work (as you noticed) and it somehow wound up being pushed to the prod repository. I’ve reverted that back to a working copy.

In general, \r is what Nextion expects for a newline character. Getting HA to send that correctly depends on the quoting you use which can be challenging.

The firmware on the device will be updated if you connect the panel to the Nextion editor and upload any HMI file over serial.

Ah ok. Makes sense now. I too have been trying to get text centered on buttons.

Personally I like 12-hour clock mode so for my clock I have:
"\"{{now().strftime('%l:%M %p')}}\""

I don’t have a USB to serial breakout/coverter board so I do the HMI download by microSD card.

Another new automation, this one for @squirtbrnr - a working alarm code panel! Code entry works like a regular keypad, you enter 4 or more digits and press “Arm” and it will submit the most recent 4 digits to the alarm system. This utilizes 4 input sliders as a rolling FIFO buffer, so you’ll need to include the new lines from the configuration.yaml for this automation to work. I haven’t deployed support for anything other than alarm_away, but it’d be straightforward to add alarm_stay etc as needed.

Hopefully this will serve as another idea for your own automations!

2 Likes

Oh sweet! Thanks! except… I have a 5 digit code :stuck_out_tongue: Don’t worry, I see how you did it and can adapt. A couple of comments/questions (and forgive me as I haven’t dug into the code yet to see what it all does): Do the sliders clear after the code has been entered? Other than adding the sliders to a group in HA then never displaying the group, can the sliders be “hidden”?

I realize if I wanted more security, I’d actually go get a real security panel that’s more of a black box than HA is. HA is great, but there’s no good way of securing data or passwords as it all sits in a plain text file structure, even with using secrets.yaml.

What I was hoping to look into myself is doing what you did with a FIFO buffer and numeric input but on the HMI. Then when a code is entered, the HMI transmits the entered code and the desired alarm state to HA, HA verifies the code and does it’s thing. Either way, doesn’t matter as I’m pretty sure basic MQTT is transmitting plain text.

Adding one additional slider and modifying the automations a bit should get you set up w/ 5 digits. The sliders range from -1 to 9, where -1 is just a nonsense number which the alarm service won’t accept. Each slider is set in a rolling manner via automation as the user enters the code and when they press “arm”/“disarm” the most recent 4 digits are sent then all the sliders are reset back to -1. The input_sliders can be hidden via hidden: true in the customization section of your configuration.yaml.

You are also correct in that all of this is sent in cleartext over your network (but encrypted via WPA2 while over the air) but for DIY work I’m not too worried as I suspect the intersection of “people who want to smash windows and steal crap from my house” and “people who can and will surreptitiously place a packet sniffer on my automation VLAN” is a pretty small set. My Honeywell alarm isn’t encrypting the transmission from its panel to the controller so apparently actual security companies have arrived at the same conclusion.

In response to the alarm panel questions I’ve added some comments explaining what’s going on, something I should probably be doing in the other automations as well. I’ve made what I think should be some final adjustments to the printed model to remove a leftover screw hole, and I’ve taken some pictures and wrote up the assembly process for the printed model including some notes on installing threaded inserts.

At this point I’m thrilled with how the completed project looks. The enclosure is rigid and everything fits like a glove. This is as close to an Actual Product as I think I’ve ever made and I couldn’t be happier with the result.

Finally got things together enough where I figured it was time to put a device together for permanent installation. Now to find out if the thing is reliable enough to run for days…

Also to find some suitable white paint for these screw heads.

I’ve also noticed that Nextion has just pushed an update to their editor software, adding some bitwise operations to the instruction set.

Presumably you could utilise this with any size nextion panel (obviously with a different bezel).

For sure! The Arduino code is setup to pass through Nextion commands meaning it should work fine with any of the Nextion panels in the range. I selected the 2.4" model because it’s the only thing I could find that would fit between the screw mounts found in standard work boxes, but if you went landscape in a multi-gang box you could fit a much larger panel.

edit: just went and checked dimensions. The 4" panel will fit landscape between the normal screw mounts in a work box (83.3mm on center), but the 5" panel won’t.

Alternately, make a frame (as you propose) and hang it anywhere you can feed it 5VDC and you can use any of their panels.

Or you could have the screen mounted on the wall surface, with the ‘rear’ unit sitting in the same box as yours.

Awesome project! Would this work with this ESP8266 board that I already have (link)?

Just to completely mess with / make an amazing extension to your amazing work done already, you could make a cover plate that snaps on over the top of the base with the screws, similar to how the Belkin WeMo wall switches work.

1 Like

The protoboard/PSU arrangement I’m using probably wouldn’t fit with a NodeMCU-style ESP8266 board, but if you can provide an external source of 5VDC you might be able to make it fit. Otherwise, D1 minis can be had for well under $3 shipped anywhere in the world.

I don’t have space to permanently mount one into a wall box, so I am looking at making some other kind of external box to free stand it on a counter or something like that. I would power it over USB most likely.

In that case, no problem. While the enclosure would have trouble with a NodeMCU, the software will be 100% compatible.

1 Like

in response to your quest to see if it’s reliable for days… I’ve experienced a few things leaving mine on for a while. This may be due to multiple restarts of HA as I update animations, etc but eventually the display backlight will get not just turned off but brightness set down to 0. This brightness setting is saved even if restarting the display. If we use ...\command\dim 10 vs ...\command\dims 10 the former is a temporary brightness, whereas the latter is saved. Not a huge deal, but I have to do a combination of toggling the backlight and changing the brightness level to get it back. The weather status on page 1 doesn’t fit “mostly cloudy” so I think applying similar font resizing like on the media player page should fix it. The sliders on page 4 and 5 work, but sometimes skip a setting and will “hop” back to a previous setting or the light will randomly change about 30 seconds later. I should have asked this long ago, but is it normal behavior for the screen to “flash” twice when a button is pressed? Almost as if the screen is getting reloaded. I don’t think it has anything to do with the automations, rather something in the HMI that causes this like the Serial and LCD can’t run at the same time on the Nextion panel.

I’m using the same ESP8266 (NodeMCU ESP-12E) and plan to protoboard it later, but I want to keep it DC powered so I can use either a battery pack or phone charger. Since I won’t be using a power supply, there will be plenty of space to rotate the ESP8266 vertically and mount the microUSB port close to the case edge.

I’ve got a 3D printed front bezel coming next week and have a switch (useless and doesn’t do anything) I will be replacing with this. I’ll also be making another soon to have in a home theatre for specific control of it.

1 Like

I’m not 100% certain I understand the issue you’re experiencing, can you break it down for me a bit? You’re correct about the difference between dim and dims. I make use of both for the auto-created Light device that should appear via MQTT Discovery. You can see the logic in the Arduino sketch here. Essentially, if the user changes the brightness value of MQTT light device in Hass I’ll apply and save the value. If they turn the light device off, I’ll save the current dim value with dims then set the dim to 0. When they turn that device back on, the previously saved brightness value is restored. Does this align with your use case? I’m concerned I’ve messed up my thinking on this somewhere and I’d love to get to the bottom of it.

I have done exactly what you’ve proposed in my dev build that I should be pushing out today, for the exact same reason (“mostly cloudy”). Good catch, and sorry about your weather :smiley:

With no automations at all running the sliders are a little… well it’s a resistive touch panel, not an iPhone. It’s bein all it can be. However, if it’s jumping around 30 seconds after the fact that means that it was updated with that new value and something from Hass made it happen. I’m still debating on the current approach (send all button on/off messages, then let the user query if they want a new value) versus putting code in the Arduino that will request a value update from every button on every release, and ignoring the error that comes back from everything that isn’t a slider. In short… I’m still not super happy with how sliders work and I think some additional Arduino love might resolve a handful of those issues.

The screen shouldn’t do that, and the way that I’m using automations is 100% at fault.

When you change pages from the panel it triggers an automation which updates the input_slider haswitchplate_active_page, which keeps Hass up-to-date about which page is currently active. When you change that slider in the UI, another automation sends a page change to the panel, so that there’s a two-way sync between the actual page being viewed and the slider in Hass. The result is that when you select a page on the panel, it changes the slider in Hass, which in turn now sends a page change back to the device for the same page which was just selected meaning it’s seeing two page change requests every time you click a page button. The page command forces a refresh of the screen, and that is why you are seeing it blink every time you change the page (but only when doing so from the panel).

I spent several days with this question rattling around in the back of my head and literally woke up one morning with the answer: when updating the slider in Hass, disable the automation that sends the update from Hass back to the panel. So now when you change pages from the panel, Hass picks up the change, turns off the Hass>panel page change, changes the Hass slider haswitchplate_active_page, then turns the Hass>panel page change automation back on.

This issue is present in several other places where things like sliders are being updated from both Hass and the panel (the media player volume slider for example), but updating the .val property of an individual object doesn’t force a screen refresh and thus there’s no screen flashing in response.

tl;dr download the latest HASwitchPlatePages.yaml and you’ll find the issue resolved.

I’ll give you a heads-up on this: the ESP8266 is a lot of things, but low-power ain’t one of them. Your phone charger will be fine, but don’t expect to see a runtime of days on a battery pack without substantial effort being made in the code to muck around with sleep states and several hardware modifications to hack out power-hungry devices like the USB UART. Even then… battery life is probably not going to be great. Expect to provide full-time power to this project.

Again, all this feedback is super helpful and I really appreciate you taking the time to write it up!

1 Like