What do you think it is possible to install HASP on LANBON L8?
The device uses ESP32.
Blakadder has successfully installed tasmota https://templates.blakadder.com/lanbon_L8-HS.html
Or maybe it will be possible to connect an esp 8266 to this LCD?
Blakadder has successfully installed tasmota https://templates.blakadder.com/lanbon_L8-HS.html
3 Likes
Probably not, the HASP project is tightly tied to the Nextion touchscreen platform. Does look like an interesting device! I don’t think it will mount in a North American work box, has anyone tried it?
@luma
is there an easy way to duplicate a page? ie i have a room that controls an outdoor fan aswell as the dining room fan. i would like to put one HASP there but control both fans. ideas?
If you have a page that works well for you, could can create a copy of the yaml with a new name, then search + replace the old page number for the new. This will only really work for those pages which offer multiple copies of the same layout, which would be pages 1-3 and 4+5.
For example, let’s say you have page 2 setup like you want, and you want to do the same on page 3. Copy the page2 yaml file to a new file in the same package folder, and replace the following:
Search: _p2 and replace with _p3
Search: p[2] and replace with p[3]
1 Like
hasp-lvgl started out as an HA SwitchPlate clone for replacing the Nextion screen with a commodity display. We have recently added Lanbon L8 support with the help of @blakadder and it runs quite smoothly.
The code-base has diverged a lot though to accommodate lvgl features and real-time object manipulation. We’re still working on HA integration but feel free to check out the daily-builds. To learn more about the project check out the documentation.
2 Likes
First things first here - HASP-lvgl is an AMAZING project and I think it will take things to the next step over time. @fvanroie is an incredibly skilled developer and he has essentially re-written the entire HASP codebase to make it portable and performant. He also happens to be super nice and helpful and generally a joy to work with. His work on HASP hasn’t been super-visible here as he’s not a Home Assistant user, but you can thank him already for developing the tools I used to create the anti-aliased fonts along with icons from FontAwesome. That never could have happened without his work on reverse engineering the new Nextion font format and helping me use the tools he created to work with it.
I think this project will be the future of HASP.
To me, the major benefit of HASP-lvgl is the portability across multiple display devices and microcontroller options. The Nextion product in use by the HASP has served us well, but the parent company has always been challenging to work with and hasn’t gotten any better over time. Decoupling the project from that vendor results in huge benefits in terms of cost, features, and product selection. It’s going to take a lot of work but for that reason alone the work feels worth it.
However, for the immediate future my time will continue to be spent on HASP for a handful of reasons. Right now, HASP is the only solution where we have a fully-realized electronic and mechanical solution suitable for use in North America, along with integration with Home Assistant. As of the moment none of those things are true with HASP-lvgl…yet. Also, I’ve sold a bunch of these things and I feel a sense of obligation to support those existing users who were kind enough to give me money with the understanding that I wasn’t going to bail on them, and I take that pretty seriously.
I will also be working towards developing a workable electronic and mechanical solution for HASP-lvgl for North American users, in a manner similar to HASP where the entire project will be open source and buildable with reasonably common tools accessible to the home hobbyist. That effort is going to take some time, so I don’t want to set any expectations. I would be surprised if anything is ready for public test any sooner than 6 months, but I’m also not the only person working on that side of things so who knows.
This is a pretty exciting development that has been the result of over a year of work led by @fvanroie. I expect good things in the future for both the HASP and also, eventually, HASP-lvgl!
8 Likes
This is great. Love to hear it.
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