Awesome project! Great job! I will definitely try and build one myself (parts are ordered! 
).
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 
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 
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.
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