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