Ahhh, better safe than sorry. However, I divulged it in an earlier photo anyway. Have a great weekend.
OK, next. So that now I have my HASPone working with a clock display and a weather display I want to be able to control some of my devices that are on Home Assistant. Starting with controlling lights. Is there a tutorial somewhere on how to setup a blueprint to control a light that is a device in HA?
Hi Luma, I am having issues with the Alarm control panel which I suspect is due to a recent update in Home Assistant (as it has worked flawlessly for quite a while). I am using the 1.06 Blueprint version and while it comes up on the display, it will not activate or deactivate the alarm system. Looking at the âTracesâ of the Blueprint I see the following error: âError in describing trigger: Cannot read properties of undefined (reading âincludesâ)â. Would you happen to know if the Blueprint needs to be updated or whether there is something I need to do in Homeassistant.?
Project should still work fine on 2026.03 (have a dozen here working as expected). Check for duplicate devices and then re-run first time setup as described here: Fix common HASPone issues ¡ HASwitchPlate/HASPone Wiki ¡ GitHub
Try recycling the power to the HASP.
i´ve solved this with help from Gemini.
changed the Blueprint Yaml´s
Share the solution, please.
i changed a few configs in switchplate blueprint.
but I no longer have the Gemini chat 
here are the Blueprint files: https://drive.google.com/file/d/16AQe86KzZ0LFGeDq3SPkQbMGCzVow9db/view?usp=drive_link
Since upgrading to 2026.3.1, all of my HASP plates exhibit this problem.
Re-run Core functionality gives this error:
New automation setup timed out
Your new automation was saved, but waiting for it to set up has timed out.
This could be due to errors parsing your configuration.yaml, please check
the configuration in developer tools. Your automation will not be visible
until this is corrected and automations are reloaded. Changes to area, category,
or labels were not saved and must be reapplied.
UPDATE
Restored a backup (2026.2.3) and all HASP units are working again.
HASPone v1.09 Release
Home Assistant Update Integration
HASPone now registers as an updatable device in Home Assistant. When a firmware update is available, it appears in the HA Settings > Updates dashboard alongside your other device updates.
- ESP8266 firmware and Nextion LCD firmware are tracked as separate update entities
- Click Install directly from Home Assistant to trigger the OTA update
- Release notes link is included in each update card, configurable per-release via
version.json - Update availability is checked automatically every 12 hours
Fix for breaking changes in Home Assistant MQTT entity naming
Big thanks to @SylvainGa for the 1.07 and 1.08 releases, fixing a breaking change in Home Assistant: Replaced object_id with default_entity_id as mentioned in warning sta⌠¡ HASwitchPlate/HASPone@68df52d ¡ GitHub
All blueprints will need to be updated! - make sure to copy down all files from Home_Assistant/blueprints/*.yaml into your Home Assistant installation.
Bug Fixes
Fixed Nextion ACK timeout logic
The ACK wait loops in nextionSetAttr() and nextionGetAttr() used || (OR) with an inverted timeout comparison, meaning they would exit immediately instead of waiting for the ACK response. Changed to && (AND) with corrected comparison direction so the loop properly waits for either an ACK or a timeout.
Fixed beep on/off state inversion
The beep feedback had on and off states swapped: analogWrite(beepPin, 254) was called during the âoffâ phase and analogWrite(beepPin, 0) during the âonâ phase. Corrected so the beep actually sounds during the on interval.
Fixed WiFi password display in web UI
The web configuration page checked mqttUser instead of mqttPassword when deciding whether to show the password placeholder. The MQTT password field would appear empty even when a password was saved.
Fixed page restore after LCD reboot
nextionReset() and espWifiConnect() compared nextionActivePage with a truthy check, which treated page 0 as âno page set.â Changed to >= 0 so page 0 is correctly restored.
Fixed debugPrint() brace scoping
debugPrint() had a misplaced opening brace that put Serial.print(debugText) outside the if (debugSerialEnabled) block, causing serial output even when debug was disabled.
Improvements
mDNS actually starts now
Added the missing MDNS.begin(haspNode) call. Without it, the mDNS service registration was configured but the responder itself was never started, so the device was not discoverable on the local network.
mDNS now advertises MAC address and MQTT server
Added mac and mqtt_server TXT records to the mDNS service advertisement, making device identification easier on the local network.
WiFi reconnection hardened
WiFi.hostname(),WiFi.setAutoReconnect(true), andWiFi.setSleepMode(WIFI_NONE_SLEEP)are now set on both initial connection and reconnectionespWifiReconnect()uses saved credentials from WiFiManager when no hardcoded SSID is configured, instead of passing empty strings toWiFi.begin()- WiFi persistence disabled during reconnection to avoid unnecessary flash writes
- All WiFi settings are reapplied after reconnection
OTA update reliability improved
- MQTT client, TLS buffers, telnet, and web server are disconnected/stopped before starting ESP OTA to free memory
- HTTPS OTA buffer increased from 512 to 4096 bytes for more reliable downloads
- Removed manual URL parsing â
ESPhttpUpdatehandles it withHTTPC_FORCE_FOLLOW_REDIRECTS
Update check rewritten for Cloudflare compatibility
updateCheck() was rewritten to use raw HTTP/1.0 requests with explicit content-length parsing instead of HTTPClient. This resolves failures when version.json is served behind Cloudflareâs edge network.
Firmware download URLs switched to HTTP
Default firmware URLs changed from https:// to http:// to reduce memory pressure during OTA downloads on the ESP8266. Previously HTTPS was used through a cloud-hosted VM which would proxy from GitHub, that now runs through CloudFlare. While this does change from HTTPS to HTTP, the security posture doesnât change as the ESP8266 does not have the capacity to pull in and validate the full cert chain so it never did actually check any part of that in previous releases. The update check itself still uses HTTPS.
Debug serial output optimized
SoftwareSerial debugSerial is now a global instance instead of being constructed and destroyed on every debugPrintln() / debugPrint() / debugPrintCrash() call. Reduces heap churn during debug output.
OTA progress display deduplicated
nextionUpdateProgress() now only sends display updates when the percentage actually changes, avoiding redundant serial commands to the Nextion during firmware uploads.
PlatformIO build configuration updated
Added monitor_speed = 115200 and upload_speed = 921600 to platformio.ini for faster development iteration.
ESPHome Example Updated
The ESPHome example configuration (esphome/haspone.yaml) has been updated with:
- Serial logging disabled (
baud_rate: 0) since the UART pins conflict with the Nextion â logs are available via the web UI and ESPHome dashboard instead - Updated
ota:to current ESPHome syntax (platform: esphome) - Detailed header comments explaining the hardware UART constraints and why SoftwareSerial is required on this PCB
- Version bumped to 0.0.2
version.json Changes
All firmware entries now include a release_url field pointing to the GitHub releases page. The device reads this on each update check and passes it to Home Assistant so the update card links to the correct release notes.
Files Changed
| File | Description |
|---|---|
Home_Assistant/blueprints/*.yaml |
New blueprints as of v1.08 for breaking changes in Home Assistant |
Arduino_Sketch/HASwitchPlate/HASwitchPlate.cpp |
All firmware changes above |
Arduino_Sketch/HASwitchPlate.ino.d1_mini.bin |
Compiled firmware binary |
Arduino_Sketch/debug/HASwitchPlate.ino.d1_mini.elf |
Debug symbols |
Arduino_Sketch/platformio.ini |
Build config updates |
esphome/haspone.yaml |
ESPHome example improvements |
update/version.json |
Updated paths, added release_url |
One note that I should mention - if youâre on 1.06 and want to update through the web page, remove the âsâ from âhttpsâ in the firmware URL, the update URL should read: http://haswitchplate.com/update/HASwitchPlate.ino.d1_mini.bin
Some explanation - SSL on the ESP8266 is extremely limited and itâs essentially impossible for it to actually validate the chain on internet facing certs from orgs like Lets Encrypt over any length of time. Previously, I made this work by running a dedicated VM in Azure which would proxy incoming connections, using the lowest-possible SSL encryption to present to the project on update checks, and then letting Linux handle the GitHub side of the SSL conversation because the GH certs couldnât be handled by the ESP8266.
That VM has been offline for a while (it was a free cloud account which I no longer have access to), which broke update checks. That functionality has been replaced with a CloudFlare worker, but CF still mandates secure certificates which once again cannot be handled by the ESP8266, so weâre back to using HTTP.
While this does mean someone can snoop on your firmware downloads, it doesnât otherwise change the security posture. The previous code did not actually check any part of the SSL cert, so there was (and still is) no protection against man-in-the-middle attacks. If someone at your ISP wants to hack your HASPone by intercepting firmware updates, I donât have a great solution to prevent that, short of using your browser to go to GH (which can do the full cert validation), download manually with your browser, and then upload locally to your device.
I just updated my firmware from 1.06 to 1.09 and the performance is a whole lot better.
I did get this error however:
sockaddr=IPv4Sockaddr(address=â10.10.10.187â, port=6053))]: [Errno 111] Connect call failed (â10.10.10.187â, 6053) (SocketAPIError)
Thanks Luma.
I updated all my switchplates without issue.
Many thanks Luma.
Thatâs a new one - where are you seeing this error? HA log, or the log on the device, or somewhere else? Port 6053 is used by ESPhome, which is not in play in this project, so thatâs a pretty weird error for a HASPone.
Quick update. This error came from the ESPHOME Builder log. Hope that helps.
This project doesnât make use of ESPhome (there is a configuration in the repo that will let you use the hardware for ESPhome but it doesnât interact with the HASPone blueprints etc). Is there any chance the specific hardware youâre using was, at one point, flashed with ESPhome and now ESPhome is trying to talk to it?
In any event, the error coming from ESPhome should not have any bearing on your haspONE functionality.
Hey, where can i find these uk faceplate stl files? Those links dont work anymore.
Cheers dude.
Luma- Are you still selling HASP kits or pre-built units?