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

[stevemann (Stephen Mann (YAML-challenged))]

@luma

Yeah, Nextion panels are sometimes better used upside down due to their viewing angle, so using the HASwitchPlate-Inverted.tft and then mounting the device upside-down in your work box might be a solution. No other modifications should be needed, blueprints etc will all work as designed.

It sort of worked. The display did invert. But, now, my HASP is bricked.
On the display, I see the WiFi is connected, but no mention of MQTT.
Cycling the power a few times didn’t change the result.

I removed the HASP from the wall and opened it to insert the MicroSD and flashed
https://raw.githubusercontent.com/HASwitchPlate/HASPone/main/Nextion_HMI/HASwitchPlate.tft
to the Nextion.

Now, HASP boots OK.

I wonder if the OTA update was the problem? I’ll try a microSD card with the inverted.tft file.

UPDATE

Hard-flashed the Nextion with the inverted.tft file → No difference. It never got past the “WiFi Connected” screen.

I hard-flashed the HASwitchPlate.tft again, and after a couple of restarts, it now boots reliably.

[lawrencez (lawrence)]

Hi Luma,

I seem to be getting to following constant errors in the config log in HA:

2021-12-30 18:59:00 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: ‘break’ is undefined when rendering ‘{%- set color = namespace() -%} {%- for entity in device_entities(haspdevice) -%}
{%- if entity|regex_search("^light…*selected_background_color(?:\d+|)$") -%}
{%- set color.source=entity -%}
{{ break }}
{%- endif -%}
{%- endfor -%} {%- set brightness = state_attr(color.source, “brightness”)|int / 255 -%} {%- set red=(state_attr(color.source, “rgb_color”)[0] * brightness)|int -%} {%- set green=(state_attr(color.source, “rgb_color”)[1] * brightness)|int -%} {%- set blue=(state_attr(color.source, “rgb_color”)[2] * brightness)|int -%} {{ (red|bitwise_and(248)*256) + (green|bitwise_and(252)*8) + (blue|bitwise_and(248)/8)|int }}’

[luma]

You’ll need to update your blueprints! That error was fixed a few versions ago, so replace the contents of <home assistant>/blueprints/automation/HASwitchPlate with the files found here.

This process is annoyingly manual - if you’d like to help out, maybe upvote the feature request here which aims to make the blueprint upgrade process a little less of a pain.

[lawrencez (lawrence)]

Thanks, working great now

[DSHAESP]

Hi. Is it possible to use the nextion editor to create pages for openHASP?

[fvanroie]

No, openHASP does not use Nextion displays or HMI files.
You need to create a JSONL file for openHASP.

[DSHAESP]

Is there any other GUI-software to create pages and export to jsonl?

[stevemann (Stephen Mann (YAML-challenged))]

Help!
I had HASP running on a larger screen with jumpers to a wemos. Worked great. It was named “desktop”.

Since then I built a desktop version using the correct display. Works great.

I wanted to change the first desktop unit name from “desktop” to “lab” for experimenting.

This is where things got bad. When I plugged in the original Wemos, Home Assistant “discovered” a new device named “desktop”. (Yes, I should have unplugged the desktop unit before plugging in the lab unit).

So, now in Home Assistant I get this:

On the “desktop” HASP, all I get is the empty Page1.

How do I fix this? Erase everything and start over?

[luma]

Try running through this guide.

When HASPone comes online, it send out a device discovery message with its device name and the “haspClientId”, which is a combination of your device name and the MAC address. If you rename the device, it should create a new device (but I don’t have any way to remove the old device). If you bring another device online with the same name, that will also create a new device because the other unit has a different MAC address which allows Home Assistant to recognize that this is, in fact, a different unit. Finally, Home Assistant will also create a new device with a new name, but because the name already exists, it will get a _2 appended.

[redford-jones]

Hoping someone can help me here. Desperate to try this project with my Nextion but i have fallen at the first step.

I have a NX3224T024_011, which I have flashed the TFT files to via SD card. I have flashed the HASPOne firmware to several different D1 mini’s (at least 4 different boards), all the D1 minis are known to work as I have previously used them for ESPHome projects successfully. I then followed the wiring and set up instructions on this page and yet I never get past the ‘HASP Initializing’ screen.

Am i missing something really simple here?

[jmyler12 (Justin Myler)]

Assuming that flash went well, every time I’ve had that issue it’s been a data issue. Do you have the RX and TX swapped? Thats what it was the last time for me.

[redford-jones]

Yep, successfully flashes every time:

esptool.py v2.6
Serial port /dev/cu.usbserial-14320
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:f4:b6:a8
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Erasing flash (this may take a while)...
Chip erase completed successfully in 8.9s
Flash params set to 0x0340
Compressed 477536 bytes to 327936...
Wrote 477536 bytes (327936 compressed) at 0x00000000 in 31.9 seconds (effective 119.9 kbit/s)...
Hash of data verified.

Leaving...
Staying in bootloader.

Firmware successfully flashed.

I have it wired as per the instructions on the link I posted:

WeMos Pin	Nextion Cable
5V	Red
GND	Black
D7	Blue
D4	Yellow

I have tried swapping the pins around too, no success there either.

[luma]

Do you see any debug log messages that you might be able to share here?

[redford-jones]

Thanks for your response @luma. I’m not sure how I can grab debug output; I can’t connect it to WiFi to give it an IP as it doesn’t get to the configure screen, so Telnet isn’t an option. If I’m reading your docs right, USB debug requires going into the web admin page on the device, which again, I can’t get to as it doesn’t get that far. Genuinely stumped as to how to go forward.

[luma]

USB debug will be enabled by default until you go through the process of disabling it on the web admin screen, so if you’re just now flashing the device and haven’t yet gone through the configuration, chances are good it’s spitting out some useful information via serial that would probably help us figure out what’s going wrong.

[redford-jones]

Thanks. Didn’t know it was enabled by default. I checked the logs, connected to the fallback AP to configure Wifi and MQTT and still no luck, still stuck at ‘HASP initializing’ - here’s the output:

[+0.089s] SPIFFS: mounting SPIFFS
[+0.124s] SPIFFS: [WARNING] /config.json not found, will be created on first config save
[+0.133s] HMI: LCD responding, continuing program load
[+0.138s] HMI OUT: connect
[+0.141s] HMI OUT: page 0
[+0.143s] HMI OUT: 'p[0].b[1].font=6'
[+0.147s] HMI OUT: 'p[0].b[1].txt="WiFi Connecting...\r IOTDev"'
[+40.518s] HMI OUT: 'p[0].b[1].font=6'
[+40.522s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\r IOTDev\rIP: 192.168.1.73"'
[+40.534s] WIFI: Connected successfully and assigned IP: 192.168.1.73
[+40.542s] HTTP: Server started @ http://192.168.1.73
[+40.550s] ESP OTA: Over the Air firmware update ready
[+40.555s] HMI OUT: page 0
[+40.558s] HMI OUT: 'p[0].b[1].font=6'
[+40.563s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\r IOTDev\rIP: 192.168.1.73\r\rConfigure MQTT:\rhttp://192.168.1.73"'
[+82.456s] HTTP: Sending root page to client connected from: 192.168.1.10
[+82.898s] HTTP: Sending 404 to client connected from: 192.168.1.10
[+136.764s] HTTP: Sending /saveConfig page to client connected from: 192.168.1.10
[+136.785s] HMI OUT: 'p[0].b[1].txt="Saving\rconfig"'
[+136.790s] SPIFFS: Saving config
[+136.794s] SPIFFS: mqttServer = 192.168.1.161
[+136.798s] SPIFFS: mqttPort = 1883
[+136.802s] SPIFFS: mqttUser = mqtt
[+136.806s] SPIFFS: mqttPassword = *********
[+136.811s] SPIFFS: haspNode = plate01
[+136.814s] SPIFFS: groupName = plates
[+136.819s] SPIFFS: configUser = admin
[+136.823s] SPIFFS: configPassword = 
[+136.827s] SPIFFS: motionPinConfig = 0
[+136.832s] SPIFFS: debugSerialEnabled = 1
[+136.836s] SPIFFS: debugTelnetEnabled = 0
[+136.841s] SPIFFS: mdnsEnabled = 1
[+136.844s] SPIFFS: beepEnabled = 0
[+136.886s] RESET: HASP reset
[+136.889s] HMI: Rebooting LCD
[+141.994s] ERROR: Rebooting LCD completed, but LCD is not responding.
[+0.061s] SYSTEM: Starting HASwitchPlate v0.40
[+0.066s] SYSTEM: Last reset reason: Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
[+0.085s] SPIFFS: mounting SPIFFS
[+0.105s] SPIFFS: reading /config.json
[+0.110s] SPIFFS: parsed json:{"mqttServer":"192.168.1.161","mqttPort":"1883","mqttUser":"mqtt","mqttPassword":"**********","haspNode":"plate01","groupName":"plates","configUser":"admin","configPassword":"","motionPinConfig":"0","debugSerialEnabled":true,"debugTelnetEnabled":false,"mdnsEnabled":true,"beepEnabled":false}
[+0.156s] HMI: LCD@responding, continuing program load
[+0.162s] HMI OUT: connect
[+0.164s] HMI OUT: page 0
[+0.167s] HMI OUT: 'p[0].b[1].font=6'
[+0.171s] HMI OUT: 'p[0].b[1].txt="WiFi Connecting...\r IOTDev"'

[luma]

Allright, so the first thing I notice is that you’ve flashed the old project! You’re going to want to make sure you’re looking at the HASPone repo here, then follow this guide to flash your device.

[redford-jones]

Well, I feel a fool! Thanks for that. It works now. Thank you so much for you help @luma

[luma]

Hey great news and glad you’re up and running!

[Sawadee]

I have three Haspone’s all have been working well up to and including 2022.2.3. Then with 2022.2.4 had issue that turned out to be a bad update involving MQTT. This affected all my MQTT devices. Core update 2022.2.5 came out quickly and fixed all the MQTT issues. But… It looks like all my Haspone’s no longer communicate with Home Assistant.
Anyone have this issue or have I screwed something up?
Thanks

Never mind… Sorry
Did a core functionality reset and all seems to be working. Need to re-select color.