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
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 
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