Updating over HTTP worked like a champ, and I didn’t lose my configuration. This helps simplify things a great a deal.
1 Like
@luma Thanks for sharing your work, this is awesome. It is exactly what I’ve been looking to replace my electric switches. I’m interest to know in the field how good is the WIFI signal when it is install? Have you though to used the Wemos with external antenna?
As for the LCD since you seem to be not limit anymore by those standard electric box, have you thought going with a Nextion 2,8" or 3.2" instead 2,4"?
My last concern is how resistant it the Nextion display and should we add a protector film in from?
The signal is going to be heavily dependant upon your particular installation, the workbox, and the rest of the environment around it. I have plastic boxes and wood framing in my current house and it works great. In my last place we had mostly brick walls or steel frame along with metal junction boxes which limited signal to some degree. While I have made use of the WeMos Pro + external antenna to enable greater WiFi range with other projects, I didn’t think it necessary for indoor use.
Still, the WeMos mini pro is pin compatible with the mini, so I suspect you could use that instead and run a bare wire antenna to wherever you think best, but I haven’t tested that personally. If you do so, keep in mind that you need to move a 0-ohm resistor on the pro to use the external antenna.
The standard electric box limit is still very much in play. The edges of the PCB for the Nextion 2.4 just barely fit between the screw lugs as it is. It would be possible to mount a 3.2 horizontally in a dual-wide box but I don’t really have a reason to do so. If you want to go full surface mount, there are a lot of tablet options out there that are probably going to be more functional and the forums here are full of excellent examples of people doing just that. HASP is all about building a small, functional, lightweight screen interface that will fit in a single box which I developed because I couldn’t find anything like it available to buy.
You know that’s an excellent question. I’ve had one of these devices on the wall of my office for about 6 months now with no problems, but it’s only been me using it and I don’t have kids banging on the thing or anything like that. The surface is glass, so it’s not likely to scratch too easily and being mounted in the wall it’s not likely to be dropped. It shows finger smudges which I wipe off on occasion, but I’ve never noticed anything else that suggested a screen protector would be necessary.
Thanks for the kind words and interesting questions!
hi , first of all super cool work and design .
i have my Tevo tornado currently printing both STL files.
i have been facing script line problems the script you mentioned in install instructions is not working for HASSio. is there a work around that should i just copy packages folder into my directory of home assistant i am really a beginner started learning almost a year back now i have my 4 rooms under automation and zwave dimmers.
please advice i would only like to have 3 pages browser with status switches and dimmers.
Thanks In Advance
I have done zero testing or really made any effort whatsoever to make this work with Hass.io. I’m honestly not even sure what would need to be done there but it might be a good idea to start digging into how Hass.io expects packages (or something like them) to work.
I didn’t have any issues integrating this with hass.io
My installation for this was different than the provided instructions, however. If you’ve got Samba running, your packages directory is under \config\packages
You can then just paste the contents of the zip file there - it should look something like this when you’re all done.
Then restart HomeAssistant and everything will be there!
2 Likes
Hey @luma I see about 2 weeks ago you updated the Nextion HMI file (the .tft file) that’s downloaded to the screen but the actual Nextion HMI project (the .hmi file) wasn’t. any reason for this? Can I get the .hmi file? I have a slightly larger HMI screen that I want to utilize so I need to change the destination screen type and test it out, but want the updated HMI with all the changes.
I should leave better commit notes 
That was simply re-compiling the TFT with the latest version of the Nextion editor, no changes were made to the HMI file.
1 Like
so till now upto my understanding everything has popped up in Hassio i belive will go down smoothly (attached pictures)
screen is in post . 2 from banggood , 1 from seller in my country 3 times the price but for early testing i went with it .
the stl files are under printing with My Tevo Tornado. (200 on END , 65 on Bed, 0.15 layer height , 75% infil, 10 top and bottom layers, 60mm/s, Cura) 8 hours print 50 mins will keep posting .
will be using LOLIN NODE MCu for this build i hope it fits.
also in orders are this 230 to 5v dc step down
also attached are picture
1 Like
More project updates
@Gagan_Kochar I hate to do this to you buddy but…
New Enclosure Models Released!
The previous enclosure models had several issues that I have been aiming to solve. The rear had several openings which is probably unsafe so I’ve published new 3D printable enclosure models with a handful of options.
Front plate models
-
HASwitchPlate_front_single.stl Standard single-wide plate.
[HASP] -
HASwitchPlate_front_double_decora_right.stl Double-wide plate with Decora switch to the right
[HASP|Decora] -
HASwitchPlate_front_double_toggle_right.stl Double-wide plate with toggle switch to the right
[HASP|toggle]
Rear enclosure models
-
HASwitchPlate_rear_lcdmod.stl The
lcdmodenclosure requires the removal of the 4-pin XHP connector from the Nextion LCD panel. This option allows for better clearance around the screw posts which may help in tight work boxes, but the process of safely removing the connecter may require a hot air station. -
HASwitchPlate_rear_nolcdmod.stl The
nolcdmodenclosure does not require removing the 4-pin XHP connector from the Nextion LCD panel. This simplifies the build process but has just a little less room behind the device for the work box screws. We’re not talking a lot here, so if you don’t have the hot air station this option will probably work fine for you.
As usual the STLs are dimensioned in mm and oriented for printing without rafts or supports.
LCD Modification
As noted above, the Nextion LCD can be modified to give a little extra room around the screw lugs which may help with mounting in some work boxes. If you have the means to do so, you can use a hot air gun to remove the 4-pin JST XHP connector from the PCB and then use the lcdmod rear enclosure model for some extra room in your box.
High Voltage cabling
I’ve replaced the existing screw-connector with wires directly soldered to the PCB egressing out of the rear of the enclosure instead of the top. This makes mounting substantially easier in smaller work boxes. The AC power cables should be at least 18AWG 300V stranded cable with a white jacket soldered to the AC/N pad on the PCB and a similar wire with a black jacket soldered to AN/L. These are fed through a rubber push-in grommet mounted into the rear enclosure. I’ve had good luck stripping an existing 3 conductor power cord and using the black/white wires inside.
1 Like
@Gagan_Kochar I am not sure if that power module is safe to put in your wall on it’s own.
This thread uses an hlk but points out the safety requirements.
https://forum.mysensors.org/topic/1607/safe-in-wall-ac-to-dc-transformers
Digging this post out of ancient history as I now have some options that might suit you @rogersmj. If the double-wide options above aren’t going to work for you, can you tell me the exact arrangement you are looking for? It should be reasonably straightforward to build out whatever arrangement with a simple copy/paste.
OK I have pulled my gear out to have another go with this.
I just couldn’t get it to compile in Arduino IDE so I downloaded .bin file that is on github. It flashed fine and I was able to connect to it’s AP and set the wifi parameters via it’s web page. I also tried to set the mqtt parameters but when it rebooted the mqtt parameters were lost. I have tried a few times via the web gui but the mqtt hostname never sticks, although the mqtt password and user seem to have been retained.
At the bottom of the page it says MQTT Status: Disconnected, return code: 0 MQTT ClientID: plate01-5ccf7fc17686 HASP Version: 0.24 LCD Active Page: 0 CPU Frequency: 160MHz Sketch Size: 426976 bytes Free Sketch Space: 2715648 bytes Heap Free: 28128
1 Like
Can you try running the “factory reset settings” option and then setting everything up again? This will format the filesystem and make sure that you have a usable configuration file to start from.
@luma still having issues with the active page restore activating multiple times… All I have to do is restart HA and it sit and spins and fires the automation nearly 30 times.
Are you running the new packages? Can you test with the latest Arduino code and a HASP device configured in hass via deployhasp.sh as outlined in the updated docs here?
Yep did all that except for running the deploy script. I read through the script and what it does and did everything manually. I setup the package, massaged as necessary for my setup, ran the initial config automation, then to troubleshoot I shutdown my MQTT server and cleared its DB and contents and started fresh. With the panel disconnected it still pops up as connected and available in HA front end and my logbook shows the automation triggering about 30 times.
All the files I grabbed from github either last night late or this morning including the Arduino sketch, the Nextion HMI, and the HA YAML files.
One other thing to try - can you unplug the device for > 5 seconds, then plug back in and see what happens? I’ve noticed an issue where LWT is being triggered after reset, but if you press the reset button (or anything that involves the device coming back online quickly), the new connection publishes its ON message before the broker recognizes that the previous session has gone offline, so it sends OFF after the ON message.
Also… Maybe rename the device using the web admin panel temporarily, then try the deployhasp.sh script with the temp name and see what happens, with no modifications being made. This will leave your existing automations untouched for purposes of testing. I ask this because I have now tested across several devices and several users and several installations, and using the packages as presented with the latest code has in all cases removed the multiple-trigger-on-connect error.
HASP Version 0.26 - full auto-updates!
I’ve just released version 0.26 to GitHub which includes an updated Arduino sketch and a couple new automations. The primary thrust of my work over the last week has been building up to this:
HASP will now check http://haswitchplate.com/update/version.json every 12 hours to see if an updated version is available. If so, a flag is raised which will change the admin web page Indicating the new version and providing a one-click button to install.
The HASP will periodically (every 5min by default) publish a JSON object to hasp/plate01/status with some useful information. I’ve added a new MQTT sensor object in the updated package which will surface the periodic status updates to Hass as a new sensor sensor.plate01_status
The primary reason behind this is to provide Hass with a notification that an HASP update is available. A new automation has been added which will check that attribute every morning at 3:00am and trigger the update process. This automation can be disabled to prevent HASP updates if desired.
The end result now is a fully automatic update process for the Arduino codebase. This is the one component of the system which shouldn’t require customization by the end user, and it’s also the core component involved in most of the bugfix activity, so I wanted a way to make sure users have an easy way to keep up-to-date with new releases as they happen. I’m not a huge fan of shipping with these updates enabled, but Hass doesn’t really provide a mechanism to package an automation which is default disabled but will remain enabled if the user elects to enable it. Let me know if this is annoying.
I’ve made some additional reliability improvements around MQTT and LWT which I mention in the post above. The broker’s LWT timeout is not configurable from the client, so I’ve updated any HASP reset routines to gracefully disconnect from MQTT before restarting the device. If you’re testing on the bench using the reset button, you may still experience timing issues where HASP will reboot and come back online before your broker notices the previous connection was lost. If you use the web interface or MQTT commands to reset the device this shouldn’t happen, otherwise you can simply hold the reset button in for a few seconds (or pull power) to give your broker a chance to issue the LWT before the device comes back online.
For normal usage while mounted in the wall this should no longer be a problem, even when restarting the device via firmware updates or pressing the reboot button.
yes, unplugging it for >5 seconds works and the automation will only fire once. but once HA reboots it will do the multiple firing of that automation whether the panel is plugged in/connected or not.
I’m not sure how much of this I can continue to use as I use the docker image on a Synology, not sure I can use the deployhasp.sh script. I’m sure I can but just cautious on what I could break.
EDIT: I’ll try the latest Arduino sketch later tonight. what tipped me off to the multiple automation triggers is I added a notify action to the page restore automation. Unfortunately while testing today, I hit the 150 push notification limit imposed by the HA app, so it’s more difficult for me to test/track now, until tomorrow when the limit resets.