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 
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!
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
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
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.”
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 
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.
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.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.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
So… what do you think?
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…
. 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…
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
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!
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.
@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?
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.
Wow. From “blueprints won’t work” to this in a couple weeks. Well done sir.