You should be able to use a NodeMCU in place of a Wemos as it accepts a wider voltage range… it’s just larger so you’ll have to modify things a bit. But if it’s going into an RV it’s not necessarily going to be in a standard electrical enclosure, right? Should give you the extra space you will need for a NodeMCU.
In the case of the NodeMCU you can just power it directly off 12v and it’ll step down the 5v used by the panel.
I’ve just ordered a raft of these guys for a customer project I’m working on. They’ll convert a 7-36VDC input to 5VDC out @ 1.5A. I have some work boxes around the house with low voltage cable run to them which I can use to power some HASP devices, so while I have these on the bench I’l be checking them out for the HASP project. If things look good I might have to add a second PCB for low-volt DC use. Stay tuned!
I was looking at using this step down regulator https://www.pololu.com/product/2831. It is only 1 amp but I have some from a previous project.
One idea I had that would be pretty safe I believe is using POE. Would be cool to just run Ethernet to the various ESP8266 sensors and do POE 802.3af. But then you think, wait. Just use an ESP32 but then you get into the whole Ethernet add-on for it and now the pricing on things just goes out the window right? So yes, the irony of Ethernet right there and you only use it for power but these are low traffic 2.4ghz devices anyways.
Might be tough to fit this all in a one gang box. https://www.amazon.com/DSLRKIT-Active-Splitter-Ethernet-Raspberry/dp/B01H37XQP8
Your idea might be better with just a stepdown converter and a simple 12vdc wall wart somewhere else.
Just Updated to the latest and greatest and that is what it is. 
Doing it in “packages” alsum make Heaps Easyer also easyer to break and unbreak
which a did a heaps of times today getting head around it
back Colours
- id: Plate01 1_7
alias: Plate01 1_7
trigger:
- entity_id: binary_sensor.garage_door
platform: state
action:
- data:
topic: hasp/plate01/command/p[1].b[7].bco
payload_template: >
{%- if is_state('binary_sensor.garage_door', 'on') -%}
2016
{%- else -%}
63488
{%- endif -%}
service: mqtt.publish
Thanks to the Guy who wrote the above it. This Haft my Automations
what about Putting it into the packages folder
when I get my head around it Ill do it still just a copy/paster at this point of time
if we could change the if to look at what was triggered one less line to change LOL
only one problem
have these
still
deleted the DB Still here
I just uploaded the .bin file to the wemos
THANKS AGAIN FOR ALL THE HARD WORK THATS BEEN DONE.
Hey @luma
I’m trying to place an order with AllPCB via your invite link, do I need to specify anything specific in the “Quote” or can I just upload the gerber zip?
Thanks 
well that is not the case in my country, may be all walls are made of bricks and concrete and no insulation panels or foam anything Fire catching is in walls .
well i was testing with no changes written by you the screen page makes it restart if i press 3 buttons , like lights on then off then day light ( or any three combination ) it restarts the screen re connects to mqtt only in case of scenes rest it doesn’t happen any where.
i hope i am able to explain , may be its cause of scenes controlling the screens brightness also.
If I had to guess, that is probably the result of an earlier version reporting itself with MQTT Discovery, and now your broker is holding onto that discovery message and playing it back whenever anyone connects. If you’re running Mosquitto, this process will clear all that stuff out.
Thanks for jumping in on this crazy idea I had and helping us make it better!
It’s actually not a fire safety regulation. The thought is that if you have high voltage cable in that box, and some wire gets frayed, damaged, etc and makes contact to the low voltage side, then you have high voltage on your low voltage cabling that you may contact elsewhere when you aren’t expecting it, with what could be surprising results.
Do you have any sense of whether the ESP itself is rebooting or just MQTT? Do you see a “wdt” message on the serial monitor when this happens?
it does say trying to reconnect wifi, then i can see mqtt logs in Hassio that it dropped and reconnected as far as wifi issue is concerned i have tried with 2 different routers rest all page works fine only happening with scenes Page. i am trying to put a ping to its ip now just to check if wifi is being dropped or only MQTT.
UPDATE: i just removed the plate_01 screen scenes from .yaml file and now it does not reboot seems like screens brightness was being changed rapidly in 2-3 second 3-4 times makes it drop connection … ( in my case)
Can you use mosquitto_sub or something similar to watch MQTT traffic, run through the process, then paste the logs on hastebin.com or similar? I’m wondering if you’re seeing some of the behavior that @squirtbrnr is reporting.
I did this process and still saw some odd behavior after clearing MQTT. Unfortunately I still have not had time to test anything, maybe this weekend.
i am using hassio core MQTT
now my demo.yaml file has this. no mention of hasp brightness and now its not doing any errors or reconnecting working like a charm
scene:
name: Lights On
entities:
light.light_1:
state: on
brightness: 255
light.light_2:
state: on
brightness: 255
light.light_3:
state: on
brightness: 255
name: Daylight
entities:
light.light_1:
state: on
brightness: 150
light.light_2:
state: on
brightness: 150
light.light_3:
state: on
brightness: 150
name: Night
entities:
light.light_1:
state: on
brightness: 50
light.light_2:
state: on
brightness: 50
light.light_3:
state: on
brightness: 50
name: Lights Off
entities:
light.light_1:
state: off
light.light_2:
state: off
light.light_3:
state: off
Do you know how to publish your own MQTT messages? If so this might clear out the earlier discovery message using the mosquitto_pub client:
mosquitto_pub -r -h hassio.local -t "homeassistant/binary_sensor/HASwitchPlate/config" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/binary_sensor/HASwitchPlate/state" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/binary_sensor/HASwitchPlate-motion/config" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/binary_sensor/HASwitchPlate-motion/state" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/light/HASwitchPlate/config" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/light/HASwitchPlate/status" -m ""
mosquitto_pub -r -h hassio.local -t "homeassistant/light/HASwitchPlate/brightness" -m ""
+1 for Ethernet versions and poe…
WiFi is easy as pi… but it does fail occasionally. Doesn’t help wife approval factor
I’m seeing the same behavior and mine is up and running off NodeRED instead of the HA automations. I haven’t checked the MQTT traffic to see if it’s sending multiple messages.
For mine, the first time I change the brightness, the ESP will lock up about 3-4 seconds afterwards. Once it reboots itself, no more lockups and changing the brightness causes no issues.
So it doesn’t seem like it’s a code issue. Could be something with the Nextion panel causing some interference that is bringing down the ESP? Outside of my league, I’m just a lowly mech e!
