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

RAM is our issue (as opposed to flash storage). Also, I don’t really want to add hot-air rework to the list of requirements to build this project :smiley:

Nextion offers 2.4" devices with more capability, but I don’t want to go changing hardware requirements as there are now hundreds of these things mounted in people’s walls.

Hi. I’m getting this warning in my HA Logs, do I need to worry about it or can I just ignore it?

Thanks

Feel free to ignore! A recent update to how automations work has brought that warning. I’ll be making some use of this new feature in the next release, it’s pretty handy in some situations!

1 Like

Hi,
My name is Stephan and I come from Germany.
I’m quite new to Home Assistant, but I have some technical knowledge.
I got the HASP up and running successfully.
Now I would like to show the remaining time of a timer.
I created an automation:

- id: '1611421186523'
  alias: 11_test_timer
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.bad_sp_connected
    to: 'on'
  - platform: homeassistant
    event: start
  condition:
  - condition: state
    entity_id: binary_sensor.bad_sp_connected
    state: 'on'
  action:
  - service: mqtt.publish
    data:
      topic: hasp/bad_sp/command/p[6].b[11].txt
      payload_template: '"{{states("timer.cooking_timer")}}"'
  mode: single
- id: '1611421367093'
  alias: 11_test_timer_akt
  description: ''
  trigger:
  - platform: state
    entity_id: timer.cooking_timer
  condition:
  - condition: state
    entity_id: binary_sensor.bad_sp_connected
    state: 'on'
  action:
  - service: mqtt.publish
    data:
      topic: hasp/bad_sp/command/p[6].b[11].txt
      payload_template: '"{{states("timer.cooking_timer")}}"'
  mode: single

But only idle or active is displayed, not the time in seconds.
I also tried state_attrib.remaining, unfortunately without success.
With sensors or input_number it works without problems.
Maybe someone had a similar problem and can give me a tip?
Many Thanks.

Greetings
Stephan

Considering a change of direction

I’ve been working on the next release of HASP for… well it feels like it’s been a long time. There’s a lot coming :smiley:

After working out the HASP firmware updates I’ve dug into the Home Assistant automations and maybe have gotten a little carried away. Above you’ll find a demonstration of some of that effort. What I’m not showing you is the YAML that created it - that one page is now more than 700 lines of not-very-comprehensible YAML.

This is the result of an idea I had, where I could create much more complicated automations and then provide a Lovelace UI that simplifies the use of these automations. That experiment is working and after a few weeks of work I have several pages which have been modified in this way. It’s slow going, but the result is really nice. As a user, you have the ability to do things like select a scene to trigger from a list of scenes, a nice button to go edit those scenes, and it’s all right there in Lovelace. Cool!

… right up until you decide you want one of the scene buttons on Page 1 to be something that isn’t a scene button. Then you have 400 lines of YAML to wade into, all of it references some other part of the automations, and it isn’t at all clear which part you would need to disable in order to create your own automation.

In creating a very-easy-to-use interface for the first-time user, I’ve also created a system that is nearly impossible to modify past the default options. This is really bugging me, because I want all of y`all to be able to make HASP your own project instead of a copy of my project. This should do what you want, and I have no idea what you want, so I’m just making it do what I want and hoping that’s going to work for you.

That’s probably bad because, in the words of Operation Ivy, “all I know is that I don’t know nothing.”

So what now?

A while back back @cbrochar asked me to check out the new Home Assistant Blueprints feature. And I did, for like 5 minutes, and determined they wouldn’t work. Later I went and dug a little deeper, ran into the same problems in my own mental model of how HASP should work, and then again determined it wasn’t going to work.

Third time’s a charm I guess, because this weekend I’ve been digging deep into what might be possible and discovered the problem isn’t Blueprints, it’s my own brain, and fortunately I can fix that problem by being smart instead of being dumb :neutral_face:

With blueprints I (or others) can publish an automation which does all the things one needs to do to populate and interact with a single button. As part of deploying that blueprint you are able to determine which blueprint will be applied to each button. So if you want page 1 to have a clock, a scene control, and a couple toggle switch buttons, no problem! Just deploy a clock blueprint, then a scene control blueprint, and then a couple toggle blueprints.

Here’s what deploying the “Trigger Scene” blueprint looks like:

One selects a blueprint to deploy and then fills in the required values: which HASP to use, which page, which button, which scene to trigger, what text to display on the button, and what font to use. Click save and now it’s deployed. If you want to make another button with similar settings (say, page one button 5 instead of button 4), you can copy the existing automation and just modify the parts you want changed.

This post is getting way longer than I intended so let’s cut to the chase.

Pros and Cons

  • The existing method of packaging automations provides for the most flexibility if you’re an automation wizard. All features of Home Assistant are available, and you can use things like helper objects, Lovelace GUI interactions, or have a mess of spaghetti automations that all reference each other. Sky is the limit.
  • The packaged automations all show up on day one. Run deployhasp.sh and boom you have a HASP that does the things I think someone wanted it to do. Flip through screens and they all have things on them.
  • Packaged automations are challenging to modify, and with each release, I wind up changing some part which means any modifications you made now require wading through thousands of lines of YAML to figure out what’s new.
  • Packaged automations all “do things” but those things are my things, not your things. Making it do your things brings you back to the problem above.
  • Using blueprint automations means deployhasp.sh has less to do, and after it runs you are the proud owner of a HASP with nothing on it. You need to do more work at step one to get HASP to be useful.
  • The current HASP UI has 58 buttons you can assign (excluding the page control buttons on the bottom). That means you need to roll out 58 blueprints, one by one, in order to populate all of them. This feels like a lot of work, but the default automations almost certainly didn’t do anything useful for most users, so instead you had thousands of lines of YAML code and far more than 58 automations to review to make use of those buttons.
  • Blueprint automations can mean you have total control over how your HASP works. You can setup each button to do the things you want through a simple workflow.
  • Blueprint automations should make it much easier for individuals to contribute their own HASP automations. Right now, that is pretty effin difficult. I think it’d be great if we had some easy way for people to contribute their own HASP hacks, and blueprints seem like a way to make that happen.

HOLY WALL OF TEXT BATMAN

Yeah OK sorry about that, I’ve been working on this a lot and wanted to check in with you folks before I spend another few weeks chasing down an idea that everyone hates. This is the part where I ask you, the person who for some reason decided to read all of this crazy stuff, to tell me what you think :smiley:

So… what do you think?

3 Likes

First, thanks for all your pass work, this work, and feature work on this project… I know it’s a labor of love, hope it will continue that way…:blush:. I have three working (mostly) in my automated home, and love them. Have some parts for 3 more. But I would like them to do more and it looks so good that one of these approaches will do just that.
Having made some page programming changes in the past, my vote is for the easiest method to customize assuming it is not to restrictive function wise.
Thanks again…

1 Like

Luma, First thanks for all of your hard work on this project! I really like the idea of being able to configure the actions as I want. It might be nice to have a default set of blue prints that do a limited set of features.

Keep up the great work!

Randy

1 Like

Luma, this is awesome. I am already implementing some of your Blueprints. I am going to try to develop some myself and share them. I think that going this route will allow many more users to share their automations.
As far as some of the cons of Blueprints, It took me quite some time to setup my HASPs the way I wanted them. I even have one that sits next to my desk for testing changes before I implement them in the production HASPs around the house. I think that 58 Blueprints isn’t too bad. Implementing the one you wrote, only takes about a minute!
GREAT WORK. I hope I get an opportunity to help with the Blueprints!

1 Like

Hi everyone,
I am happily running two haswitchplates! I was just wondering if somebody figured out a solution better than mine to automatically dim the display (let’s say to 20%) when not touched and automatically dim it to 100% once it is touched (but without any effect). As an example: I’m not using the display for 5 minutes, it dims to 20%, I touch it wherever and it dims to 100%, then I touch it again to activate the button I need.

The solution I came up with is extremely complicated and not very smart: add an if argument to every single button/slider/whatever that if the display is dimmed <100% it dims to 100%, else it just does what the button should do.

make a file in the packages / plate name / hasp_diningroom_00_noinput_dimbacklight.yaml

inside the yaml paste the below: (make sure to change the plate name to what yours is called)

timer:
  hasp_diningroom_backlight:
    duration: '00:00:05'


automation:
- alias: hasp_diningroom_00_BacklightBright_TimerReset
  trigger:
  - platform: mqtt
    topic: 'hasp/diningroom/state/#'
  action:
  - service: timer.start
    data:
      entity_id: 'timer.hasp_diningroom'
  - service: mqtt.publish
    data:
      topic: 'hasp/diningroom/brightness/set'
      payload: '255'

- alias: hasp_diningroom_00_BacklightLow_trigger
  trigger:
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.hasp_diningroom
  action:
  - service: mqtt.publish
    data:
      topic: 'hasp/diningroom/brightness/set'
      payload: '10'

Thank you so much! But how can you see what button you’re pressing when the dim is 10/255?

I have something like this for a nightmode. I switch the backlight off at night as it is disturbing…

However I had to change all automations to only react if the backlight is on. So first touch activates the backlight at night and then, if the backlight is on the normal automations are triggered. so basically I added a condition to all button automations.

1 Like

@snizzleorg, could you share an excerpt of your code, please? Especially to understand how to use an appropriate template.
Thanks!

set it to 20/255 like you wanted?!??

So you can never turn off the display light completely with this solution, although it is more agile.

you can turn it to what ever

But then I will just blindly activate any button just to reset the light to 255, am I right?

All blueprints, no packages

I’ve managed to re-create all of the base automation requirements for running the HASP into one “core” blueprint, and I’m now creating blueprints for several example solutions to display things on the HASP or make Home Assistant do things when a button is pressed. This turns out to be pretty powerful and it is now extremely easy for the end user to completely customize HASP without touching a single line of YAML.

Here’s an example of what things look like today:

Starting with a blank HASP configuration, I browse through the available blueprints and select one that will show a clock. The description shows a preview of what this blueprint will do, and offers documentation on the various page/button layouts and details on the fonts that are available.

This blueprint offers several configuration settings. I select my target HASP, leave the defaults, save the automation, and hit execute to fire the automation right away. Then, I change the font and click the option to show am/pm, then click save and then execute again to see my changes.

With this approach, available HASP function can be cooked into a blueprint and shared via the forums or GitHub. You can import the blueprint directly into Home Assistant from URL and then deploy for as many buttons as you wish. Deployed button automations are all editable later.

This is going to change a lot about how HASP is setup and used. I have a lot of documentation to do yet but the basics are very simple. There is no more deployhasp.sh, no more packages, and no more YAML to edit. Simply import your desired blueprints and then assign them to buttons on each HASP page.

7 Likes

Sounds fantastic @luma

Wow. From “blueprints won’t work” to this in a couple weeks. Well done sir.