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

Ugly hacks incoming and time for some thoughtful decisions

Iā€™ve been pulling my hair out trying to hunt down an issue raised by @squirtbrnr which results in a huge rush of MQTT traffic between HASP and Hass. Iā€™ve finally pinned the cause down to the behavior described in this bug report. Sadly, it doesnā€™t look like this behavior is going to change which leaves us with a problem.

The Problem

A short version of the problem is something like this: when Hass is using MQTT discovery (something I really like and make a lot of use of both in this project and other places, turn it on!) it winds up subscribing to the homeassistant/# namespace at least twice. When the HASP sends a status or command message under homeassistant/haswitchplate/#, the MQTT broker will send one message to Hass but it will be processed twice, and any resulting automations will likewise trigger twice. Worse, this can lead to a race condition where Hass and the HASP wind up in a loop, shooting messages back and forth which are being doubled by this behavior every loop until something breaks (usually HASP).

The Solution

I believe the only real solution here is to make a compatibility-breaking change to the existing namespace. In short, weā€™re probably going to want to move from homeassistant/haswitchplate/nodename/command to something like hasp/nodename/command. MQTT discovery announcements and interactions will remain under homeassistant/binary_sensor/nodename and homeassistant/light/nodename.

We could change the discovery namespace but that will impact any other MQTT Discovery-enabled devices you are using which seems like a bad decision - if Iā€™m going to be breaking things, I want to contain the damage to HASP without introducing problems with other solutions you may already be using.

The Impact

This should be a simple matter of search and replace for your existing automations, but any advanced templates may require more thought. Iā€™m also making some changes to the Arduino code to limit the impact of duplicate commands, so new firmware will be incoming as well.

The Question

What do you think? If anyone has any input or suggestions as to alternate ways around this Iā€™m all ears. Getting this put together may take me several days based on other time commitments, so we have a few moments to stew on this. However, maybe keep this upcoming change in mind before investing too much time into funky template-based automations :smiley:

This sounds similar to Tasmotaā€™s approach.

I think moving away from prefixing homeassistant/ would be a good idea since HASP is a separate device that is consumed by HA, not a part of HA

1 Like

The fix seems pretty straight forward and isnā€™t really much of an issue when taking it all over into node-red either, really. The only annoying thing about autodiscovery is removing auto detected devices if youā€™re working on them or change their name here like this!

Iā€™ve re-written major sections of the Arduino codebase and the Hass automations to move everything under hass/<nodename> only to find out most of the problems persist. A lot of the automations are triggered by the device coming online, which is determined by the binary_sensor device created by MQTT discovery, and thatā€™s still under the homeassistant namespace and thus will still fire twice.

The workaround suggested in the bug report works, but does so using a condition that then breaks several automations that are triggered not just by the panel coming online but also by other, unrelated actions. So for automations which are purely triggered by the HASP turning on, this is OK. For other automations, itā€™s still a problem.

I donā€™t see a way around this short of ditching MQTT Discovery in favor of requiring the user to create an MQTT binary_sensor and light device.

Other changes made to the code have removed the amplification effect (to an extent) so itā€™s now just being fired twice (not 10 or 12 or whatever times). Still, it will be very easy for a user to implement what should be common-sense triggers which will result in the same cascade of automations triggering. Iā€™m not seeing much way to avoid this short of getting everything out of the homeassistant namespace, including the 2 devices that had been auto-created for the user via discovery.

If itā€™s one MQTT discovery device, Iā€™m fine creating it and ditching discovery all together.

Better fix it properly than come up with some special workarounds. I believe everyone using your code are able to modify the mqtt topics in configurations anyway :slight_smile:

Awesome work, I also ordered the nextion display based on your post! Kudos!

I appreciate the support guys :smiley:

I think Iā€™ve got an elegant way to handle this and several other issues regarding running several plates in one installation through the use of packages. I have a basic setup working and am wading through all of the existing automations to get everything in line. The result will be a cleaner setup, easier installation, and will greatly simplify using more than one HASP.

now for the ugly part: itā€™s going to require reworking pretty much any automations you might have deployed. :frowning:

Massive Update - BREAKING CHANGES

Iā€™ve just pushed out HASP v0.2.0 to GitHub which addresses the issues Iā€™ve been posting about above and several others that have been bugging me for a while. Unfortunately, that comes with a complete rip-and-replace of the existing MQTT namespace which means any existing customized automations will need to be modified. On the plus side, there are a lot of improvements!

Change List

  • New namespace hass/nodename/ replaces homeassistant/haswitchplate/nodename for all uses. See documentation for details.
  • Home Assistant Packages HASP now lives in a Home Assistant Package which makes setup and integration into your existing config a one-line change. Download the code, copy it to hass, and add the package.
  • Zero-config Arduino Sketch The updated Arduino code uses WiFiManager for wireless config using a computer or mobile device to define WiFi credentials, HASP node name, and MQTT broker info. The sketch can be flashed straight from the compiled binary, meaning no need to muck around with libraries or Arduino code customization.
  • Multi-panel ready Several details have been modified and new capabilities implemented to allow for easy deployment of several HASP devices without requiring a bunch of customization. Package folders can be copied for new devices with a simple process.
  • Mirror-panel support You can now set up two or more panels using the same node name without conflict. Both devices will mirror each other, so when you change pages on one, it changes on the other(s), when you interact with the backlight it will set all mirrored panels, etc.
  • Loads of performance and reliability fixes Iā€™ve identified and resolved all issues that Iā€™m aware of with the codebase, resulting in much better speed, increased overall reliability, and better resilience/recoverability when errors are encountered.


Iā€™ve also designed some new faceplate options which I have printed but have not yet placed into my walls, so Iā€™m going to hold out on publishing those until Iā€™m 100% confident everything fits like it should. Expect that to happen in a few days. Once those prove out I can pretty easily create triple/etc wide variations on the theme through some simple copy/paste in SketchUp.

2 Likes

Create new HASP plate instance

To create a new HASP device , open a shell in .homeassistant and execute the following command:

bash <(wget -qO- https://raw.githubusercontent.com/aderusha/HASwitchPlate/master/Home_Assistant/deployhasp.sh)

You will be prompted for the new device name, it will then download the packages from GitHub, rename everything as appropriate, and move it under packages/<new_device_name>. Restart Hass and youā€™ll have a new tab with all of your device controls.

Upgrade from earlier versions

If youā€™re re-flashing over an earlier (pre-v0.2.0) release, be sure to clear out any saved flash contents from the system when you first flash the image. Select Tools > Erase Flash> All Flash Contents before uploading the software to your device.

3 Likes

In future revisions, would it be possible to assign wifi settings in the Arduino sketch, allowing WifiManager to become an optional feature? I personally donā€™t like having to connect to an AP to configure the device, itā€™s an extra step for something that is a static configuration.

Also when the AP is created after flashing, itā€™s an open AP but the LCD displays a password

done!

Release v0.2.1

Now the sketch allows for manually entering WiFi creds which will skip the WiFiManager autoconfig entirely. Once it has connected to WiFi (using either method), an administration portal is made available so you can change any other necessary settings through a web browser. You can protect the admin panel with a username/password, and that password is also used for Arduino OTA updates. Iā€™ve also disabled telnet (but you can easily re-enable for debug) in an attempt to get this thing a little more secure for home deployment.

Hereā€™s a look at the new admin interface:

Thatā€™sā€¦ unexpected. Can you try the new release on GitHub and tell me how it goes? Can you confirm your OS hasnā€™t saved the password?

1 Like

Iā€™ve made a new deployment script which makes adding panels to your environment a snap.

cd ~/.homeassistant
bash <(wget -qO- https://raw.githubusercontent.com/aderusha/HASwitchPlate/master/Home_Assistant/deployhasp.sh)

You will be prompted for the new device name and everything else happens automatically. The latest automations are downloaded from GitHub and everything is renamed for your device then copied into your packages directory.

I flashed the latest code to a new wemo d1, and the AP was secured.

The new admin interface is a very welcomed addition. +1

The new integration with HA with ā€œpackagesā€ is awesome, it seems to be a rather clean solution.

1 Like

With the web admin panel you can now add it to Hass in an iframe (so long as youā€™re not doing SSL). The deployment script will pull this configuration in, but leave it disabled due to the SSL thing.

Next version will have Arduino firmware update via HTTP upload, allowing you to upload and flash firmware images to the device from within the Hass UI itself. Iā€™ve also resolved the issue which was requiring a full wipe of SPIFFS. What this will mean is that once you have the device flashed for the first time, you will no longer need to use the Arduino IDE to flash the device moving forward.

3 Likes

Arduino sketch v0.2.3 has been uploaded to GitHub. There are some performance improvements along with web-based firmware update through the admin panel. Currently this only supports uploading from a local file. Youā€™ll still need to use the Arduino IDE once for the initial programming, but afterwards you can download the compiled .bin file from GitHub and upload it to the device without the Arduino IDE

To enable this capability weā€™re going to need some more room for flash space. In the Arduino IDE select Tools > Flash Size: > 4M (1M SPIFFS).

Iā€™m pushing toward GitHub integration, which will one-click updating but Iā€™m stuck on an issue with GitHubā€™s SSL cert and the ESP8266ā€™s handling of it. Once we get past that problem future firmware updates will be a one-click operation. Everything there is working against non-HTTPS servers and against other SSL-protected systems, but I strongly prefer to have it pointing directly at GitHub vs spinning up my own OTA server for everyone to use. If no resolution comes from this Iā€™ll see what alternatives I can come up with.

Enclosure ideas

This project originally started with trying to source an LCD touchscreen that I could mount between the top/bottom screw pattern in a standard workbox. The Nextion panel selected was the only option I found which would fit (and for which I could actually program against without enormous effort), but even then it only barely fits. Iā€™ve been designing against the common blue-plastic workbox you see everywhere along with some online dimension drawings Iā€™ve found for the same. Iā€™ve been running a single HASP device in my office which fit fine, but now that I have some PCBs Iā€™m ready to start deploying these around the rest of my house and have found that the existing design is a very tight fit in some of my other boxes, to the point where I had to dremel one out to get the case in. This doesnā€™t seem ideal.

Iā€™ve also been monkeying around with how I can better enclose this thing such that there are no exposed components in the finished design for safety reasons while still fitting between those two screw holes.

With the current published model there are two places where we have holes open to the outside that arenā€™t going to be easy to address (the USB access port is simply for dev work and with OTA updating is no longer necessary). These are the openings for the LCD PCB and 4-pin XHP connector, and the opening for AC power connection.

AC Power connection

The incoming power connection sticks out of the top of the unit and has a pretty large gap to insert wires. This is a huge safety problem, it exposes the only high-voltage contacts in the system and opens them facing upward, perfect for dust or whatever to fall directly into the box. This seems bad so Iā€™ve been kicking around some ideas to address it.

I started with designing a retainer plug and printing it in semi-flex TPU to clamp in the wires, fill the gap, and provide some modicum of strain relief. This approach actually worked OK but it still has cables egressing out of the top of the device in what is already going to be a cramped box. Pics below show the design and printed results along with another part Iā€™ll be discussing in a moment:


While chewing this over with @zombu2 on Discord he suggested running the power cables out of the back. The more I thought about this approach the more I like it. I have a rigid surface back there with room for a grommet, it moves the cables away from the already-tight perimeter, and it wouldnā€™t require a change to the PCB. I can simply remove the screw connector, insert the incoming AC cables from the back side and solder them to the PCB on top. Iā€™ve ordered some grommets to test fit some ideas around strain relief, but I think this approach might be how I move forward with the design. It neatly solves the safety problem, provides for sturdy cable capture, and removes the cable harness from the already-cramped top/bottom of the box making for an easier fit in your existing box.

I donā€™t have those grommets quite yet so Iā€™m testing printing a basic design with holes for the wires. Note the much deeper cutouts for work box screw mounts, something possible now that Iā€™ve moved everything out of the way top/bottom. With the screw connector gone I can also put the 4th screw mount for the LCD and front panel back in place which is a nice bonus.

LCD PCB and connector

In the current design the top and bottom edges of the LCD panel are exposed. On the bottom this is simply due to room between the screw mounts and saving myself a single mm by leaving just that edge exposed to the outside. On the top it also has the 4-pin JST-ish XHP-kinda connector up top which we never have been able to use. All existing builds (at least those that have been put into a box) have required soldering the wires directly to the solder pads of the connector. That doesnā€™t bother me so much, but having the connector itself exposed to the outside top of the box is problematic for all the reasons outlined above (only this time w/ 5VDC instead of 120VAC).

My first approach to solving this problem was the same as above - print a semi-flexible plug that I can stuff into the connector as a dust cap and hope for the best. While this covers the exposed pins it still leaves open gaps around the perimeter and takes up a fair bit of real estate. After stewing on this for a bit it occurred to me that this whole thing would be better if the connector itself were simply gone. A few moments with the hot air station proved this out pretty well:

With the connector out of the way I am now able to fully enclose the case such that no conductive parts are exposed to the outside which is critical for safety. We can do it without changes to the HASP PCB (which is handy because Iā€™ve already sold a handful) but at the cost of requiring the assembler to have access to some means of removing the connector which is going to be tricky with a standard soldering iron. Youā€™re really going to want a hot air station to make that happen.

Iā€™m still running some prints and have some parts on the way (grommets/screws/etc) to test out some ideas, so this is all very much work in progress. If anyone has any thoughts or ideas to share, Iā€™m all ears!

1 Like

Really like this work.
I orderded a Nextion a week ago.

Installed de arduino sketch to an nodeMCU whitout problems.
But the nextion Firmware file (tft) hangs, the nextion boots but hangs on ā€œSD Card Updateā€¦ā€. Iā€™m currently running Linux, so i have to use the SD update method.
Any one else encounterd this problem?

Can you post a link to the exact panel you ordered?