I have a small off brand battery pack (I’m guessing no more than 2300mAh) and I got roughly 24 hours of runtime and that includes turning off the screen backlight for at least 6-8 hours. Not stellar by any means and annoying to have to recharge everyday. The battery pack I have planned for the home theatre controller plus I want to add IR send/receive to that version. I only need it to be powered for 6-8 hours at a time and really only weekends.
So for the backlight issue I’m experiencing… I turned the backlight off from HA frontend, but left the brightness slider at 100%. The screen turned off as expected. I left it like this for most of the day and was working on other sensors/automations/configurations that required me to restart HA a few times. I come back and turn the screen on from HA frontend and nothing happens on the panel. the first time this happened, I unplugged the panel and plugged it back in and the screen stayed off (hence my suspicion of dims vs dim). I then toggled the screen from HA frontend again and still nothing. Only after going into the backlight state card in HA frontend and seeing the backlight slider at 0, and changing it at least once, did the screen actually turn on. But at no time did I ever change the brightness, I only toggled it on/off. Somewhere in those restarts I’m wondering if it took the screen off command and set the brightness to 0. I haven’t played around with it too much since the two times it happened to me and have just left the screen on all day since then. I may play around with it again today and see if I can get it to do it again.
I saw in the automations the automation.turn_off for the page update and it caught my eye. reading through how it works and it seems pretty clever. A bit of a hack but it works. I haven’t found a nice way to update a slider externally so I see where the issue comes from. As for the brightness sliders and the values hopping around… I may have just been too impatient and kept moving the sliders and not giving MQTT or the lights time to react. One of the lights a slider controls is on Z-Wave, the other two are also MQTT lights, so the MQTT server may have been just a little busy.
Thanks for the updates to the code! I’ll go grab them and play with them today.
Allright in response to this discussion I’ve made some substantial changes to the Arduino code with how it handles objects which hold a value (sliders, dual-state buttons, checkboxes, radio buttons, etc). Now when any object issues a touch event (“Send Component ID” checked on Touch Press or Release events in the Nextion editor), the Arduino code will request the current value of the “.val” attribute of that component and publish the result as state/p[1]b[2].val, which is the same as before when the device was manually queried. The only difference here is that the value is always queried upon any touch release event, saving the user from having to ask for the new value in a Hass automation and reducing the time required to react to the new value.
The downside is that we’ll be generating a lot of errors on the panel as we request value updates for things like normal buttons, which don’t have a value. This is only visible if you’re tracking the debug logging and is never sent over the wire to Hass so I think this shouldn’t impact anyone in any meaningful way, apart from the fact that you can now remove the request to update state automations for handling sliders.
I’ve updated all the pertinent automations to reflect this new feature and have done some general re-organization of how those automations are put together. I’ve also put the 3D printer automations back into the repo with some substantial changes that make it a pretty damn usable display (if I do say so myself).
I made some minor edits to the HMI (and compiled TFTs) to make the media slider value global. I mention this because the new HMI file will require the new Nextion Editor released yesterday and you’ll be prompted to upgrade if you haven’t yet.
edit: Another fun feature I added a while back but I don’t think I’ve mentioned: if you send the command sendxy=1 like this: mosquitto_pub -t "homeassistant/haswitchplate/HASwitchPlate/command" -m 'sendxy=1' the device will start sending state/touchOn and state/touchOff messages with every detected touch interaction with the x,y coords sent in the message payload. This doesn’t require a button object or anything else, it’ll just begin shooting out messages for every finger stab at the screen.
How to: Run this software with an ESP8266 but no LCD panel
One feature of the Nextion Editor is the Nextion Simulator, which allows the user to debug an HMI being edited. You’ve probably used this if you’ve worked on editing your own HMI file. You can run through the screens using your mouse to issue touch commands and feed it commands and see output in the text boxes provided.
The documentation isn’t super clear on this, but the simulator allows you to run hardware-in-loop with your microcontroller. If you have a second USB UART kicking around (you could use a second WeMos or Arduino if you have one handy), connect the UART RX to pin D4 and the TX to pin D7 which are the pins you’d use to hook up a real panel. In the Nextion Simulator you can then select “User MCU Input”, select your UARTs COM port, set the Baud to 115200, then click Start.
Now the Simulator will accept input from and send output to your flashed ESP8266 without having an LCD panel on hand!
I got my panel a few days ago and have setup page number 6 for a bunch of individual lights. It would be pretty cool if you could see at a glance which lights are on or off. Is there any way to make the buttons change color based on their state?
I’m planning on modifying your 3D files to make a table top mount and keeping it USB powered since I don’t have any unused single gang boxes to install these into.
absolutely. look at how the page tabs at the bottom are setup and you can use a similar automation based on light/device status to change the background and the text colors.
HASwitchPlateWeather.yaml line 28, replace the wrapstring="\\r" with wrapstring=\\r otherwise HA (yaml) complains about expected <block end> but found '<scalar>'.
EDIT: hold on. That gets rid of the error, but causes nothing to be displayed on the screen on that button. Looking into it further.
EDIT 2: you can also add single quotes on either side of the payload_template so it looks like: payload_template: '"\"{{ states.sensor.pws_weather.state|wordwrap(20, wrapstring="\\r") }}\""' however I’m still getting nothing showing up on that button.
I can’t seem to reproduce the issue with the current automation. It’s “mostly cloudy” at my place which results in font 1. I changed the wordwrap to 10 just to see if it handled things correctly and the message came across to mqtt and the panel as expected. If you do a mosquitto_sub -v -t "#" then manually trigger the automation, what do you see being sent?
If I am using a NodeMCU ESP-12e for this project, can I power the display straight from the ESP board or do I need to use an external 5V source for it? I was thinking I would power the board with a 2a 5v USB supply and pull 5v from VIN on the board to power the display, but as a rookie at this I haven’t been able to confirm that it will work properly this way. Anybody see anything wrong with this solution?
Hmmm, I must’ve either copied something in wrong or tried to copy the changes from GitHub manually so I didn’t break any of my current automations/programming. After verifying and copying the code from GitHub again, It’s working. Sorry for the false alarm.
I’m still experiencing a double flash of the page when I click on a button. I’m going to re-read what you posted about the page slider and look over my automations again to make sure I’m not missing something else.
Unfortunately I don’t think I can verify MQTT. I run HA in a Docker Container on a Synology NAS. So I more or less just have to trust MQTT is working right and sending the correct info.
if it’s a deep box, it might fit. I’m not sure how big the Sonoff is, but I think it might be too wide to fit in a single gang box. If you are electronics/prototyping inclined you can probably fit a small 3.3VDC/120VAC relay and terminals onto the protoboard and hook up the relay coil to a spare discrete output on the Wemos/uC.
Hey @luma I had a bit of an “ah-ha!” moment. Since you’re now using the .val property of HMI objects, this might simplify the Alarm component of the panel. I believe the numeric object of the HMI has the .val property and can be set to global. You can then tie that numeric component to a built in keyboard (numeric or alpha-numeric) of the HMI. Then the HMI would be able to pass the entire number instead of doing a rolling FIFO with sliders. Side note, although you can use the customize option hidden: true, the sliders still show up in the states tab and show the values. Once the numeric entry has been entered, it returns to the HMI page then you can press “Arm”, “Disarm”, etc and have an automation to clear out the number on button press. Now the number is stored only on the HMI until cleared, transmitted plain text over MQTT, and used in an automation under payload_template: to arm/disarm. Additionally, the number isn’t “accessible” from the frontend of HA and only used in automations. This is what I was originally trying to think of instead of re-engineering a keypad.
Those all seem like workable ideas! I’ve avoided the built-in keyboard command as it is just godawful ugly and you have very little control over the placement or look/feel of the result. There are several keyboard examples posted to the Nextion forums which folks could use if so inclined. It should be possible to use Nextion code to create a panel with numeric entry and a rolling 4digit code response which you can print and it will be caught by the Arduino sketch and sent back via MQTT.
I’m limiting my examples to Hass automations as I want the HMI and Arduino code to be usable without modification for simple use cases. My thinking there is that most of the audience is likely more familiar with Hass automations than Nextion or Arduino code, so I’m including very simple examples that should be flexible starting points but which should probably be modified to better fit your own particular use cases.
I like these panels well enough but good lord some of their UI examples are just eye-bleeding. Their questionable aesthetic choices made a little more sense after I saw this promotional video they posted a few months ago.
agreed the built-in keypad is pretty ugly. It’s flat, but for me coming from an industrial automation background, it’s actually not too bad. I can see where this would be a one-off deviation from the original goal of the project. Other than modifying the HMI to have a numeric object with keyboard attached, there shouldn’t be any modification to the arduino code, and mostly just changing the HA automations to read the .val of the numeric object on button press. I might have some time tonight to play around with this idea and report back.
@squirtbrnr thanks. I’ve actually never seen a Sonoff component in person, but they didnt seem huge. The insteon micro units are really truly small and I’m thinking they could fit. I could do this w/ a relay myself, but honestly, I dont want too. In part, I’m worried if it would violate any electrical code or expose my to some risk w/ my insurance IF something should go wrong. Probably wouldnt… but I am paranoid about that.
That’s the same reason I didn’t include relays in my original design - any time you’re mixing high and low voltage there are a bunch of considerations from NEC and UL (etc) and I didn’t think it wise to have people deploying something that could potentially be dangerous.
The only Sonoff device I have is the basic single-relay version and it for sure won’t fit in a box. Insteaon or Z-Wave micro switches/dimmers should have no problem.
One consideration with this project (and any automation control project), mains (high voltage) and control (low voltage DC or AC) really should never pass through the same conduit, enclosure, panel, box, etc. The exception being endpoint/conversion devices such as power supplies and transformers where there is a clear division and physical separation of the two voltages. In this case, the enclosure and internal circuit board is that physical separation. Ideally there should even be two separate circuit boards only joined by the transformer.
Also, if replacing a physical switch with an electrically controlled switch (relay) there needs to still be a physical shutoff to load side of the circuit for things like changing a light bulb. In my case, the switch I am replacing only controls an outlet on the opposite side of the room. With some re-wiring I can make that outlet always hot, and power this device from mains.
I’m very fascinating with this project. Listen for some reason, i can’t seem to get my LCD panel enhanced model up and running. I successfully flashed the LCD by using a micro sdcard and after reboot, all i can see is the “Initializing…” screen, nothing more. Any idea…
