can you post GitHub link for HASP2 cant find it in google neither GitHub.
can anyone show the wiring schematics for the transistor and the resistor, on the wiring and how to in the guide it only shows the schematics without it, but if you buy the board you need it. Cant you wire it like that if you already have the BOM and don’t need the PCB, Currently just testing reliablility, might end up buying the pre made board.
If you’re wiring up on a breadboard for prototype, feel free to skip the resistor/transistor bit as you won’t be needing it anyway. Those form a simple low-side switch to allow the HASP to power cycle the Nextion in the rare event that a firmware update doesn’t go well. For a device that’s mounted in your wall, it’ll take a screwdriver or a trip to the breaker box to make that happen without the switch circuit. For a device that’s on your desk in front of you, you can simply pull power whenever needed if a development cycle goes sideways. As a result you aren’t losing anything you’ll need by skipping the switch, but if it’s going in your wall, I’d recommend wiring up that switch for convenience purposes. Part cost is a few cents.
So - for the bench version feel free to follow the schematic here, or check out the full schematic with the switch below, or grab the KiCad source files from the project and you can interact with the design files directly.
1 Like
You can find the repo here: GitHub - HASwitchPlate/openHASP: HomeAutomation Switchplate based on lvgl for ESP32
HOWEVER - do keep in mind there is zero Home Assistant integration at this moment in time. This is still very much an experiment and early in development. I had avoided bringing the topic up here because I don’t want to confuse people or get the pot stirred up about something that’s still a maybe.
So, just in case it wasn’t clear: HASP is still where the project is at for the immediate future.
HASP-lvgl is an experiment to see if we can’t re-platform off of the Nextion product line onto cheaper/better LCDs with more options for users to choose from. It means re-writing all of the stuff that Nextion does out of the box, and they did that with a team of coders over the span of years. It’s a test to see what is possible, and which might wind up being the future of HASP at some point down the road if things bear out.
For now, HASP is still the project, and work continues on bringing new features to HASP users.
@lumathanks for all the info! I’ll give it a try!, I am also checking other MQTT displays like this one: https://github.com/sieren/Homepoint
As mentioned earlier, the next release of HASP is going to require re-flashing the Nextion to allow for an 8x increase in the communication speed between the display and the microcontroller. While I’m at it, I’m considering making a small change to the way the page 4+5 sliders work.
The Nextion project is stone out of RAM, we are using every possible byte which means I cannot add any more buttons without removing something somewhere else. However, I find the sliders on pages 4+5 difficult to use for a few reasons, one of which is that there isn’t a good way to use them to control on/off which is a pretty major oversight.
What I’ve cooked up is the solution you see below. The text label you see above each of the 3 dimmers is already a button that can be used, but it’s much too small for my fat fingers to reliably poke at. So, instead of adding a new button (which we can’t do without deleting something else), I’ve made the slider a little smaller, leaving some room on the left. I’ve then extended the label button down and pushed it backwards in the stack, so it lives “under” the slider. Then, I can overlay an on/off toggle icon on the button so one can tell at a glance if the device is on or off, and push that button once to toggle the light state.
Here’s how that looks:
I’m also working on creating UI elements in Lovelace which will allow one to change which devices are being controlled by each HASP right in the UI without having to deal with YAML. The scene above demonstrates a few things. Each slider can be assigned to control any of your existing light. entities by simply selecting the desired entity from a drop-down list. The text above each slider can be setup in a form field, and the Font selection is also a drop-down where you can select from the fonts available in the project.
5 Likes
the 4mb memory on the back of the nexion can be desoldered and upgraded to 16mb if space is an issue just like upgrading the fake wemos minis from 4mb to pro 16mb they are Winbond 128Mbit SPI Flash Memory 8-Pin SOIC, W25Q128JVSIQ/TUBE £1.42 each from RS components
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!
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
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 
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.shand 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.shhas 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
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…
. 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!