Yeap On dump Question where does the colours from
only way I found was open the HMI editor and play with the colours there is there a beater place.
You know if you read the thread, or search this thread for the term ‘color’ you may achieve enlightenment 
I wrote a little about this here. Editing the HMI is perfectly valid and is probably a good way to go for complete customization. However, you can also send commands to the existing HMI to change the color of various UI components using MQTT, but you’ll need to automate that somehow so that it is applied every time the panel comes online.
Project Update
I’ve spent the weekend tracking down an annoying bug that appears to be a problem with Hass when MQTT discovery is enabled. The result of this bug is slow or unresponsive behavior as hundreds of duplicate MQTT commands pass back and forth between Hass and the HASP. I am going to continue working on mitigation of this issue from the HASP side, but I’m kinda stuck on the Hass side until the bug is addressed.
As part of this troubleshooting process I’ve replace PubSubClient with Arduino-MQTT. The maintainer of PubSubClient appears to have gone dark, the issues list and PRs are stacking up and no new releases been packaged in two years while already-solved bugs persist in the code. Arduino-MQTT doesn’t add a lot of capability but it is actively maintained, and has the slight advantage of not requiring modification of the library headers to enable MQTT messages longer than 128 bytes.
I’ve modified the example configuration.yaml slightly to utilize the embedded broker just for simplicity’s sake.
As I’m stuck on the duplicate message issue, I’m going to start work on WiFi autoconfig to see if I can’t make the first-time setup a little easier.
Yes, I’ve run into issues with the PubSubClient as well blocking communications of things with my little NodeMCU sensor module. Looking at a few of the MQTT clients to switch to.
Even the Tasmota development has brought in some alternatives due to this:
https://github.com/arendst/Sonoff-Tasmota/issues/1992
One of the ones I was looking at recently as well below, I’ll have to check out the one you linked too:
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 
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 
Awesome work, I also ordered the nextion display based on your post! Kudos!
I appreciate the support guys
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. 
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/replaceshomeassistant/haswitchplate/nodenamefor 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