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

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.

Is this behavior being seen with the latest Arduino code? I’ve shuffled some things around which may help with MQTT performance. Node-RED shouldn’t be a factor on this side.

There should be no worries on that front: I’ve setup CloudFlare to sit in front of this which can handle more bandwidth than we’ll ever see, so feel free to hammer away. It’s all static content, all being served from cache, It won’t cost me a nickel, and it won’t impact performance.

Still haven’t had a chance to drop your Node-RED config into my deployment, but I would expect that you’re right. The behavior that I’m dealing with is specific to Hass (but acceptable per the MQTT spec). I really like Node-RED but I’m also not targeting it quite yet as it adds another level of complexity to an already-complex setup. I do think it’s easier to use (for people that understand it), but for the moment I’m going to continue targeting hass automations as a lowest common denominator.

Think I have found a little problem its working Great AS

But if I do a “reload Automation” the screen stop working and the automation in the Plate01 folder dispair screen does not work ie touch not working

I Think that could be a HA problem as HA reloading the automation but not the ones in the Plate01 folder

now I reboot the screen it display the ip address and he MQTT Connested with the ip address that it
but the backlight works as can switch screen on/off from HA so some thing happening

I do a HA restart and all automations come back screen still as above

all automation in the Plate01 folder are off

I turn it on those automations and screen goes to the last screen number NO text then It reboots by the looks
then everything comes back as it should be and working GREAT again.

bye the way did auto update that work alsum but dont like a idea of the else updating so I have turn that off just wanted to test it happy with that.

on my next days off ill take a automations from the plate01 folder and put them into the HA automation and redo the test and report back

Sadly, the “reload automations” thing apparently doesn’t work with packages :frowning: You’ll need to restart Hass to take in changes.

Bugger

I though it mite of been me

@luma, I wonder if you might let this guy know if his plan is viable?

1 Like

nice idea

but think there MEM be to small problem mite not fix

I’ll check this for you today. Was busy this weekend out at some autocross events so I haven’t even touched a computer all weekend. My auto update should have run so it should be all up to date.

I like the idea and I just bought another 3-pack of Sonoff basics the other day. The Sonoff just has extremely limited memory and storage space… but I’ll try it out and see if I can figure out what the demands of the program actually is. This might work!

FYI no more reboots when changing brightness on a fresh reboot, at least so far!

1 Like

I happened to notice after the latest HASP update, seeing the following in the home assistant error log whenever the HASP publishes a status topic update.

No matching payload found for entity: plate01 Connected with state_topic: hasp/plate01/status
‎8‎:‎21‎ ‎AM components/binary_sensor/mqtt.py (WARNING)

It’s not super simple to figure out which variable is having the payload issue. I tried added the status JSON parameter to the main status sensor but that didn’t seem to correct it. Thoughts?

Getting the same WARNING

Its to do with HA and the mqtt.py

I think the mqtt.py over thinking the topic (thats my understanding of it).

Have put a Feature Request in.

plz comment on that topic if like of dislike the Idea

hello wonderful people in this group , i have one question its regarding yaml and mqtt which is not related to this topic but i have been wanting help from so many days posted in so many different related topics no one responds will be very helpful if any one here can help and no one kicks me out for asking things like these here sorry you guys dont have to as its not topic related here goes,

i have a dimmer this its audrino code i can get the dimmer to work on off commands but the devloper insists mqtt payload needs to include the word Dimmer:50 but to my knowledge pay load has to only be words numeric value is sent thru slider

scovered through the internet some one with openhab had same dimmer with same problem but some one helped in community and solved his problem https://community.openhab.org/t/mqtt-dimmer-command-payload-help/39337

the arduino code shared by dev is

for (i = 0; i < length; i++) {
buf[i] = payload[i];
}
buf[i] = ‘\0’;
String msgString = String(buf);
Serial.println(" message: " + msgString);

if (msgString.substring(0,6) == “R13_ON”)
{
Serial.println(“Dimmer:99”);
}
else if (msgString.substring(0,7) == “R13_OFF”)
{
Serial.println(“Dimmer:0”);
}
else if (msgString.substring(0,6) == “R14_ON”)
{
Serial.println(“R_1 switched via web request to 1”);
}
else if (msgString.substring(0,7) == “R14_OFF”)
{
Serial.println(“R_1 switched via web request to 0”);
}
else if (msgString.substring(0,7) == “Dimmer:”)
{
Serial.print(“Dimmer:”);
Serial.println(msgString.substring(7,9));

this is my yaml entry

platform: mqtt
name: “test light”
command_topic: “bruno”
state_topic: “bruno”
payload_on: “R13_ON”
payload_off: “R13_OFF”
brightness_command_topic: “bruno/Dimmer”
brightness_state_topic: “bruno/Dimmer”

tried with “bruno/Dimmer:”
the developer keeps saying payload command is Dimmer:xx

this is the whole story , please help TIA

is it necessary that automations remains in the packages folder can’t we use use entties and do new automations like we would i understand editing old ones makes it easier

also @luma do you have STL for snap on front plate with no screws in front just to hide screws will like to give it a try if its there

Thank you

I don’t really understand what that project is all about and the GitHub page doesn’t tell me anything useful (and I don’t want to sideline this thread) so what I’ll offer is this: Hass can send nearly any MQTT message you tell it to. Check the docs on using mqtt.publish here and how Jinja2 templates can be deployed here. If you have specific questions relating to how Hass can send a specific message, you’ll probably find help here in the forums or in the official Discord chat for Home Assistant here.

You are free to setup the automations any way you like! I am distributing them using packages for a bunch of good reasons, but feel free to tear into them and modify at will. The one downside is that it will be difficult for others to answer questions about your own setup if you get too far off the path, so understand that doing so is going to require that you take ownership of the environment from that point forward. So long as you’re OK with that, there’s no technical reason you couldn’t or shouldn’t put the automations where you feel they would work best for you.

Snap-fit front plates aren’t in my current to-do list but the source 3D models are available and usable in the free edition of SketchUp if you’re interested in making changes for your own use!

@Daemonic Did you manage to get any further with this? I’m looking for solutions for mounting in the UK.

@luma How can I execute the deployhasp.sh if I don’t actually have access to a full CLI (I’m using HassIO). Is there something else I can do? I have access to the filesystem, I just can’t run very many commands.

The deployhasp.sh script does two things:

  • downloads hasppackages.tar.gz and extracts it to the packages folder under your hass installation
  • renames the files and does a search/replace on everything inside the files from plate01 to a new device name provided by the user

So, you can download that same file and extract it into your hass.io installation under packages and so long as your one HASP device is named plate01 (the default name), then it should work without further modification. If you want to deploy additional devices in your environment (or if you want to rename the one you have), you’ll either need to figure out a way to run that script or handle the file and contents renaming manually.

At some point I’m probably going to have to learn how hass.io works on a test system somewhere as the topic keeps coming up. I know others here in the thread have successfully deployed this under hass.io so I know it works, but I’ve done nothing to simplify or document the process for this project which is something I probably should be doing.