IT’d help a bunch if anyone had a chance to post MQTT logs of this happening. Better still with timestamps, which you can do something like this:
mosquitto_sub -h <mqtt_host> -t '#' -v | xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T.%3N $0"'
1 Like
I’ll try that in hass.io, but I’m not sure if it’ll work as the SSH client and Mosquitto run in separate docker containers. I have MQTTFX on my desktop at home and once I’m back there I’ll see if I can dump the messages. My board isn’t installed in the wall yet either so I can also log serial output.
The SSH add-on should include mosquitto_sub so I suspect this should work for you.
Serial logs would also be helpful if you have it on the bench, it’ll have additional debug output and timestamps too.
Much like people don’t get the point in grounding a simple light switch in a plastic box with a plastic faceplate. A lot of “if’s” but what happens when the face plate is changed to a metal one and a hot comes off or arcs to the face plate.
1 Like
Yup, that’s that exact reason those devices are grounded. In our case, the plate can’t be swapped so I think we’re in the clear on that. NEC might seem restrictive but it’s all there because something awful happened at some point and the result is 100+ years of collected wisdom of how to avoid Bad Things Happening under nearly any circumstance.
Yes, I do think that would be fine, it would pass my “sniff” test at least. I hate those metal plates anyways, just seems like an accident waiting to happen.
The mosquitto_sub command you gave me bonks and says there’s no d option. I ran the command to just dump MQTT traffic… so no timestamps, but here’s the output:
https://hastebin.com/isetusanov.bash
I started the HASP (was already on the lights page), selected brightness twice, then the ESP froze, and rebooted itself. The serial debug is just over USB but it seems to close the serial debug once it has booted. Is there an easy way to ensure it stays outputting over USB? If I disable serial.swap() it doesn’t communicate with the Nextion panel any more
SYSTEM: Hardware initialized, starting program load
[+0.055s] SPIFFS: mounting FS...
[+0.083s] SPIFFS: mounted file system
[+0.114s] HMI OUT: page 0
[+0.119s] HMI OUT: 'p[0].b[1].txt="WiFi connecting"'
[+0.125s] Connecting to WiFi network: KittenWar
[+1.133s] WIFI: Connected succesfully and assigned IP: 192.168.1.11
[+1.140s] HMI OUT: page 0
[+1.144s] HTTP: Server started @ http://192.168.1.11
[+1.151s] ESP OTA: Over the Air firmware update ready
[+1.158s] HMI OUT: page 0
[+1.166s] HMI OUT: 'p[0].b[1].txt="WiFi connected\r192.168.1.11\rMQTT Connecting"'
[+1.174s] MQTT: Attempting connection to broker <redacted> as clientID plate01-60194703cae
[+1.231s] MQTT: subscribed to hasp/plate01/command/#
[+1.238s] MQTT: subscribed to hasp/plate01/light/#
[+1.245s] MQTT IN: 'hasp/plate01/light/status' : 'ON'
[+1.297s] MQTT: subscribed to hasp/plate01/light/#
[+1.302s] MQTT: binary_sensor state: [hasp/plate01/status] : [ON]
[+1.309s] MQTT IN: 'hasp/plate01/brightness/status' : '216'
[+1.323s] HMI OUT: 'p[0].b[1].txt="WiFi connected\r192.168.1.11\rMQTT Connected\r<redacted>"'
[+1.332s] MQTT: connected
[+1.336s] HMI OUT: page 0
[+1.338s] SYSTEM: Init complete, swapping debug serial output to D8
Late edit: I’m expecting to see that there’s no obvious sign in the MQTT traffic nor the serial output - we’ll just see a watchdog restart on the ESP. I don’t have a reliable power supply around but I suspect separating the Nextion power off the Wemos would potentially help… or doing something to filter the serial channels. I don’t have a nice scope either to take a close look at the signal. Mine most definitely reboots only once after a manual power up/reset and then is stable for days afterwards… or at least as stable as any other ESP chip I’ve got. They all seem to reboot on their own eventually.
Running Hassio Dont think that command will work
thanks
The serial.swap story
tl;dr
After the device has been powered on, connect a jumper from D8 to TX and you will see all serial debug output. Remove that jumper for USB flashing, power cycling the device, or using the hardware reset button. Alternately, you can enable telnet debug in the code, recompile, and telnet to the live system to get the same info.
long boring version
The serial.swap thing is in place due to issues around how ESP8266 and the WeMos have overloaded certain pin functions for both serial and controlling the boot order. The Nextion panel occasionally runs into problems when running under softwareserial so it needs to be connected to a UART. Connecting it to the main RX/TX pins prevents USB flashing from working. serial.swap moves the pins around, but then the system won’t boot because D8 is overloaded to control boot order. The end result is that the serial communication with the Nextion is split between Serial 0 post-swap to D7 for receiving input from the panel to the ESP8266, and Serial 1 on D4 for sending commands to the panel. Serial0 is used for debug messages after the swap on D8, but having that connected during a cold boot will once again prevent the system from booting.
1 Like
Finaly got my hands on a windows machine 
But i got stuck on the next issue. I couldn’t upload the TFT file trough a SD card. (it says wrong device model.)
So i uploaded the HMI file trough the nextion editor. This went ok!
But now the screen is stuck on initializing. Any idea, i’m doing wrong?
Possibly nothing at this point! Just go through the procedures outlined here to get Hass to tell the panel what to do. You’re almost there!
Story time always fun 
Here’s the output from the serial log - actually nothing of note. I changed the brightness a couple of times, it froze, it rebooted itself without any message.
[+21.587s] HMI IN: [Button OFF] 'p[4].b[7]'
[+21.591s] MQTT OUT: 'hasp/plate01/state/p[4].b[7]' : 'OFF'
[+21.600s] HMI OUT: 'get p[4].b[7].val'
[+21.604s] HMI IN: 0x71 0x8f 0x0 0x0 0x0 0xff 0xff 0xff
[+21.609s] HMI IN: [Int Return] '143'
[+21.662s] MQTT IN: 'hasp/plate01/brightness/set' : '143'
[+21.668s] HMI OUT: 'dim=56'
[+21.672s] HMI OUT: dims=dim
[+21.746s] MQTT IN: 'hasp/plate01/brightness/status' : '143'
[+21.752s] MQTT IN: 'hasp/plate01/light/switch' : 'ON'
[+21.759s] HMI OUT: dim=dims
[+21.763s] MQTT IN: 'hasp/plate01/command/p[4].b[7].val' : '143'
[+21.771s] HMI OUT: 'p[4].b[7].val=143'
[+21.871s] MQTT IN: 'hasp/plate01/light/status' : 'ON'
[+26.763s] HMI IN: 0x65 0x4 0x7 0x1 0xff 0xff 0xff
[+26.768s] HMI IN: [Button ON] 'p[4].b[7]'
[+26.772s] MQTT OUT: 'hasp/plate01/state/p[4].b[7]' : 'ON'
[+26.779s] HMI OUT: page 0
[+26.788s] HMI OUT: 'p[0].b[1].txt="WiFi connected\r192.168.1.11\rMQTT Connecting"'
[+26.796s] MQTT: Attempting connection to broker <redacted> as clientID plate01-60194703caeHow is this device powered? USB, or via the Mean Well PSU on a PCB?
edit nevermind, just read your previous post 
I would strongly recommend testing with a dedicated source of power that can handle ~600ma.
I think I’ve identified the issue - several automations are triggered with - platform: homeassistant / event: start and for whatever reason that is resulting in all of those automations firing a bunch of times when hass starts. Commenting those triggers out has resolved that behavior without any impact to the overall functionality as they are all also triggered on the hasp/plate01/status = ON message which I’ve sent retained, meaning hass should pick that up when it connects to your broker anyway. I’ll be pushing out new packages with this change here shortly.
Based on input from @Gagan_Kochar I’ve also discovered that several buttons are triggering Hass twice. For examples, pressing the first scene button “Lights On” sends the message ON on topic ‘hasp/plate01/state/p[1].b[4]’. Hass responds by firing hasp_plate01_p0_PageButton1Actiontwice, despite the trigger condition only happening once.
The issue is once again related to how hass handles MQTT subscriptions. The hasp_plate01_p0_PageButton1Action automation (along with 2 and 3) subscribes to hasp/plate01/state/+. hasp_plate01_p1_SceneButton4 subscribes to hasp/plate01/state/p[1].b[4]. When a message on the topic hasp/plate01/state/p[1].b[4] is picked up, it matches the subscription from both automations. It doesn’t match the condition on the first automation, but it’s still being picked up twice because hass will fire an event again for a given automation if the incoming topic matches some other automation’s trigger even when it’s filtered out of that other automation via a condition.
The only solution that comes to mind is to force ALL subscriptions into the exact same subscription string and apply conditions to ALL automations to avoid this behavior. This sort of thing is addressed in the MQTT spec. I strongly suspect that something like this is also happening in the first problem I’ve outlined above but I’m not clear on exactly why. I’m going to stew on this a bit, but I suspect a rewrite of nearly every automation is in order to prevent hass from spamming multiple MQTT messages in response to every interaction.
edit: ignore all that dumb crap in the last paragraph - much more elegant fix incoming!
1 Like
HASP v0.27
Several major fixes to MQTT behavior in response to all the great bug reports I’m getting here (I appreciate it!).
Arduino code updates
- WiFi SSID and password settings added to web admin page. No “scan” option (and I don’t think I’ll be adding it any time soon) but if you need to switch networks you can now do so in the web page by typing in the details.
- Nextion commands over MQTT have been fixed (broke several versions ago and lol test coverage)
- Reduction of retained messages, now only retaining the main
statemessage - Debug output over the normal serial port! After typing up all the serial.swap thing above another idea occurred to me - I’m now using SoftwareSerial on the TX pin after it has been swapped. The result is an uninterrupted stream of debug output after the system boot. NOTE: this is going to provide dicey output (at least it does on my test units). SoftwareSerial + cheap crystals + cheaper UARTs + 115000bps is going to involve some noise. If you want output without occasional glitches, you’re going to have to hook back up to D8 where the original UART-driven output will be available.
- Added Nextion panel model detection while I try to get Nextion OTA updates to be semi-reliable
- New handling of page reporting, no longer report page changes to page 0 to prevent edge cases where the system will stick on the “Initialization” page after an MQTT reconnect
- Several changes to Nextion OTA without a goddamn bit of difference in the outcome. Still too broken to release.
packages updates
- Page flip automation templates removed and replaced with static subscription strings to prevent double-firing of button events
-
homeassistant.starttrigger removed to eliminate hundreds of automation triggers on Hass restart - enable HASP iframe in hass by default. If you’re running SSL, this isn’t going to work so maybe you can comment it out. For the rest of us it’s just too good to pass up.
- added
sensor.plate01_statusto group, good catch @ShadowDrake!
For those of you with auto-update enabled, this will be the first test of the HASP update system. Some time within the next 12 hours your device should check for an updated version, find it, and then the next morning at 3am it should try to apply it. I’m confident this will work but… interested in independent confirmation
Again, big thanks to everyone pitching in with the bug reports!
After more reflection… I wonder if the auto-update thing is a great idea. I’ve moved that over to the examples section. Normal update checks using the admin web page will continue to work as normal, but I think having an auto-apply-firmware every 3am thing is a little dangerous until I have the ability to better test and stage updates.
That reminds me… I ripped all of the platform: homeassistant / event: start out of my original automations right off the bat (pre v0.20). I’ll try that when I get a chance and see if it still happens.
Eureka! it works… Thanks
1 Like
Yup just over USB for now. I need to get out that way and snag one of those PCBs and maybe an extra power supply from you then make the thing real and put it in my intended location finally. But to be fair it does it off all 3 power sources I’ve had it on for testing - my desktop on a USB 3.0 port, my Surface pro (USB 3.0) and a standalone 36W USB charger.
I think it’s a good idea but it should be up to the individual to enable. Having it enabled by default is okay tooo - maybe just expand on the instructions on how to turn the automation on.I know, it’s really simple to do, but your project has a pretty large scope and is a little intimidating to the new person… additionally you’ve made everything super simple to deploy so someone doesn’t have to be aware of all of the automations in order to implement this in their HA instance. Adding a specific instruction might just serve as the extra awareness about the option which would be helpful for new users.
But, it’s just a suggestion. Doesn’t mean that it’s a good one. FWIW I reduced the frequency of the auto updates for mine to once per week when I ported the automations to NodeRED as I felt that was totally adequate and didn’t want to hammer your DNS forwarder. Just imagine if me and 20 of my friends decided to deploy 20 of these each haha
Did you happen to test the NodeRED deployment? I didn’t notice any double message firing with that setup… also the automations and messages seem to be much faster on my RPI3. Even toggling the automations on/off takes some substantial time in Home Assistant. NodeRed seems to run much faster for the level of automation complexity.