That is a pretty interesting idea but I don’t see a natural way to do this within the current framework provided by Home Assistant. The Device Registry only handles devices and entities. While the device view does show you automations which interact with the device, there isn’t any real relationship there that is accessible from an automation or a blueprint.
Still, I think I get what you’re after here and if features are added down the road that could expose these relationships, I might revisit this. I think it would be valuable.
That’s essentially what a blueprint is! You (or somebody) provides a “template” of an automation in the form of a blueprint, and then you can spin off several copies of that as automations.
Started down that path a while ago and decided against it for several reasons. ESPhome is an amazing project, but it’s a project with its own goals and roadmaps and existing assumptions about the world that don’t always align with HASP.
It becomes a control thing, if I piggyback onto that project, I’m left to deal with changes in that project’s direction as decisions there are 100% out of my control. I deal with enough of that on the Home Assistant side, it’s a constant source of extra work for me, and I’m not terribly interested in compounding the problem on both sides of the project.
HASP, in its current form, is probably going to stay on its own firmware. It has one thing it does, and doesn’t aim to be the central IoT platform for all of your sensors etc.
That said… the above statement does not necessarily apply to future projects.
That’s essentially what a blueprint is! You (or somebody) provides a “template” of an automation in the form of a blueprint, and then you can spin off several copies of that as automations.
I am finding it bit unwieldy after I get past 2 plates (Largely due to the lack of automation folders/tagging). You still have to wire everything up and if you want to change things, you have to change the wiring for each device and when it’s in the wall, it’s a PIA!
Here’s my use case, I have a long hallway with a plate on either end. I want the same menu structure on both plates and ideally, I would like to modify the automations once and have it deployed to all devices after testing.
You can do exactly that with blueprints today. When you import a blueprint, it becomes the base for the automations that are created from it. The blueprint defines “inputs”, which are all the settings you choose when deploying it. The automation created contains a) the input values you selected and b) the name of the blueprint which that automation is tied to.
So, if you start creating blueprints instead of automations, you can go and edit the blueprint file, do a “reload automations”, and now all automations that you created from that blueprint are updated.
Yup … there are options and you have done all the heavy lifting in figuring out “a way” that can be used as a model for other approaches … gota love Open Source!
BTW, thanks for all the work you have put into this project … I am in awe of your skills.
Blueprints don’t solve my problem as you still have to wire the blueprint to the automation for each button on each device … this is going to lead to an unwieldy number of automations. This is going to be a whole lot of development and management if you have more than a few devices IMHO.
FYI, I have been playing with your Blueprints and copied and created some of my own so that’s easy enough. It’s the long term development and management that are my concerns.
I have a heap of little AM312 PIR modules which are quite tiny and simple to use. Over here in Australia our front face plates can easily accommodate a 2.4 screen and an AM312 in a very tidy layout.
The intent then is to have oneself walk up to the switch plate with the backlight off … and the PIR detects ones presence and switches on the backlight. Then using your motion blueprint goes back to backlight off after 60secs of no motion activity.
I’m going to try to shut down the range of the PIR by some creative manipulation of the lens cover, hope fully getting it to trigger when one is only within a foot or so.
I saw that the D0 D1 Attribute was on the HASP admin settings page but once enabled still didn’t work.
I can wait though … better for you to get the formal version released and move us off DEV
I’m super excited to be setting up my first (also pre-made) HASP today! However, I already ran into an issue before even getting the MQTT server connected to the HASP.
Somehow, an admin interface password was set. Since I am not yet connected to MQTT, I cannot send a reset request.
So far I have tried:
Pressing the rest button the Wemos D1 Mini
Reloading the HASP binary using the suggested NodeMCU Firmware Programmer
Uploading a blank EEPROM sketch via Arduino, which leaves the screen blank, then installing reloading the HASP binary with NodeMCU firmware programmer.
However, these all bring me back to the same screen on my display, showing that I’m still connected to Wifi and MQTT connection is failed and retrying in 30 seconds.
Any advice would be greatly appreciated by this HASP n00b.
When you try to hit the web page, I’m presuming here that you are being asked for a username and password, correct? If so, what happens if you provide the user “admin” with no password?
That did fix my previously mentioned issue, thanks! The flash erasing tools I was using were not working. Gonna keep that one in my tool box. Haha
However, now I cannot seem to connect to my MQTT server still. I get the RC code 0, which is a confusing error code saying that the connection was accepted… lol
Is there a way to connect the HASP to a plug-in power source for testing and initial setup. I’m soon going to order one and I will want to do the initial setup with it sitting next to me in my offfice where I can easily play with it in HA and see the results. The alternative is that I mount it where it’s going in my kitchen and play with it while sitting at my kitchen table. Is there some easy way to connect it to plug-in power? FWIW I’m a software techie, not a hardware techie. Thanks.
There’s a USB port inside of the device but you’ll need to disassemble the unit to get at it. Otherwise, if you have some lever nuts/wire nuts/etc, you can strip the end of a lamp cord and connect it to the power leads for testing that way. That’s the approach I use for testing the final assembly.
New to HASP project and just build my first one after getting the parts from mouser. I really like the project and this would be perfect in my house if it wasn’t for the terrible viewing angles of the display. Some of the pictures I have seen on here seem way better then what I get. I can’t even read the display if it would be mounted on the wall a foot below eye-level.
I saw that ITEAD sells one branded with their logo. Is this one better, is the one from Amazon any different or is it a quality control issue?
Sorry for all the questions, I really want to make this work as it’s a fantastic solution!
This has been an ongoing concern over the past couple of years. The units purchased from ITEAD are no different, the problem is Nextion themselves (not that they will admit to it). For whatever reason, some units have poor off-axis viewing from above but work fine from below. One solution that many have found helpful is to flip the display upside-down, and flash the HASwitchPlate-Inverted firmware to the LCD.
Thanks luma, it does seem a little better upside down but not great.
After doing some more reading this does seem to be a big issue with many. I’ll order one from Amazon also and hopefully it’s better. If anyone has any input on a good source… please share
instead of using the PIR i’ve opted for a timeout on the touchscreen events themselves. initial screen is the info display with time, temp etc brightness is set depending on sun elevation and if the kids are in bed. when touched the display brightness turns up and starts a timer. each time the screen is touched the timer resets. once the timer reaches 0 it resets back to the info screen and dims the panel. that way you have a ‘clock’ and other info displayed all the time.
