Correct on all accounts! I have a big pile of PCBs here and am ready to ship when you’re ready to order
Just need the location to order them. Looking at the displays (https://www.amazon.com/dp/B07BL3D5DW and https://www.amazon.com/dp/B07QWS2N48) is the enhanced version better to use or the original. The only things I was seeing the enhanced really offered over the basic was larger flash and faster CPU.
Enhanced offers some more functionality, an RTC, and several new commands. None of them are used in the HASP project as it’s designed for the Basic line. So, you’ll get a faster CPU which can be helpful, but otherwise it’s not going to do much for you.
So is the differents between the K and T model 32meg vs 16meg memory only? Tnx
See the datasheet here.
None of these features are used in the HASP project, and also the 2.4" Enhanced PCB will not fit into the existing project enclosure due to the coin cell holder.
You’re really best off sticking with the part recommended in the BOM.
I am hear in Australia and am wondering if the screen I can get here is compatible with your Nextion code, here is the screen: https://www.jaycar.com.au/240x320-lcd-touch-screen-for-arduino/p/XC4630
The wifi module https://www.jaycar.com.au/wifi-mini-esp8266-main-board/p/XC3802 looks fine as it is a ESP8266.
Looking just as a proof of concept first so interested in giving this a crack.
Thanks
Girkers
The D1 mini looks like a clone of the real D1 mini, so it might work with the PCB design. The display is for sure not going to work, Nextion displays have their own processor and firmware, which is stone required by this project.
You can try openHASP for ESP32. There is also WT32-SC01 build for that device.
Cool thx I loaded some demos on it look awesome. Its a must have shiny thing .
Who wants to test the new release?
I’m at a point where I feel like everything with the new release is stable enough to have a few people try it out and tell us how it goes. There are a few gaps in functionality (see below), but to my knowledge the major bugs have all been worked out and I could use some help identifying the ones I haven’t found.
What’s Missing
Currently, a couple features of the current HASP automations have not yet been converted into blueprints. If you are dependant upon the following features, know that they are coming but not available via blueprints yet:
- Alarm panel control
- HVAC control (but you could still do this with the blueprints available today)
The other thing missing is…
NO MORE PACKAGES
That’s right, no more deployhasp.sh
, no more packages, and most importantly - NO MORE YAML. Obviously, writing your own automations via YAML is still supported, but it’s no longer required to setup a HASP the way you like it.
The other thing missing is extensive documentation Now that I think things are approximately where I want them, work on making this easy to use via simple documented steps can begin.
How to test
Getting an existing (or new) HASP up and running on the new version is reasonably-straightforward.
-
Make sure you’re running the latest version of Home Assistant. We’re making extensive use of blueprint and MQTT features just released in 2021.2.
-
Disable any existing packages or other automations for HASP (if it was already deployed): Under your
homeassistant
folder you should find a folderpackages/<hasp name>
. You can safely delete this or move it to a temporary location under some other folder for safekeeping, such ashasp-examples
which should already be there. If this is the last HASP (or your only HASP), you can also move/delete the filepackages/hasp_demo.yaml
. -
Update HASP firmware: On the HASP web administration page, go to “Update Firmware” > “Update ESP8266 from URL” and enter this URL:
http://haswitchplate.com/update/dev/HASwitchPlate.ino.d1_mini.bin
-
Update LCD firmware: After a minute HASP should reboot. Once it’s online again, go back to “Update Firmware” and under “Update Nextion LCD from URL” enter the following URL (new code supports HTTPS now!):
https://raw.githubusercontent.com/aderusha/HASwitchPlate/dev/Nextion_HMI/HASwitchPlate.tft
-
Confirm HASP Connectivity: HASP should now be sitting at an idle screen, showing its assigned IP and the IP address of your MQTT broker that it is connected to. If that isn’t the case, use the web administration page to get things sorted out. It needs to be online and talking to MQTT before you proceed to the next step.
-
Import Core Blueprint: In Home Assistant, go to “Configuration” > “Blueprints” then press the “Import Blueprint” button at the bottom right. Enter the following URL:
https://github.com/HASwitchPlate/Blueprints/blob/main/hasp_Core_Functionality.yaml
Click “Preview” and then “Import” to add it to your list of available blueprints. -
Deploy Core Blueprint: From your blueprints list, find “HASP Core functionality” and select “Create Automation” to the right. The only thing we have to do here is to select your HASP, click the drop-down next to “HASP Device” and look for “(your hasp name) Connected”. Select that, click “Save”, and then press the “Execute” button at the top-right.
That’s it! You now have a working HASP. It won’t do much except flip between pages until you deploy additional blueprints for each button you want to configure.
You should have a notification in the Home Assistant UI, click that to reveal some Lovelace code for an “Entities Card”, you can copy that code, create a new Entities card, show code editor, and paste everything there (overwriting the defaults). That’ll give you some quick controls over the HASP.
One feature that doesn’t really matter but I’m super proud of:
This is the result of months of bug stomping. From pressing reboot, connecting to WiFi, connecting to MQTT w/ TLS enabled, subscribing to all the required topics, triggering Home Assistant to send the configuration, to processing that config and sending it to the Nextion - completely ready for action in under 3 seconds.
Great timing! Installing my first HASP is my project of the day, and I was hoping I could use the new blueprints approach. I’ll check back in to let you know how it went!
How would I use the blueprints to recreate the High, Med, Low buttons on the fan page? I figured out how to make a simple button that toggles and shows the state, but I’m not sure how to make the button state change based on the state of the fan.
Great! I like it! a lot!
I think it would be good if when page scrolling is activated the scroll buttons would show the next page name.
otherwise how would one create scroll buttons? I mean some kind of symbol?
Also another question. I really like the idle sleep function. but ideally during day I do not want it. I have a night mode input_boolean. would be nice to integrate this somehow.
I guess I can turn the automation on/off but when I turn the automation off while the display is in sleep mode it remains there, while ideally it should return to its normal operation state.
I also would recommend a different scroll mode (through the pages)
Page 1, Main , Page 3 main pages
then when on page 1
<< Page 1 Main
then when on page 3
Main Page3 >>
Turns out, you can’t do that with the blueprints I’ve provided! I’m trying to sort out a way to extend the Toggle blueprint to allow tracking attributes in addition to state (done) and also to allow you to specify the service call to use (not done). Idea being one could say “track this attribute”, and then define a service call + options to toggle the state.
If I can’t make that fly, then I’ll probably wind up creating a “fan page” template that mimics the original HASP functionality. My only reservation with that is that it’s hard to modify by the end user, so I’m going to keep chasing down the first option here.
Let me stew on the best way to handle this. I have a few ideas that might work.
Can you explain a little bit more about this? I’m not sure I understand exactly what you’re saying here.
For example, let’s say the user has 5 pages defined in their scroll list, like the nonsense example below. How should that appear on the 3 page buttons for each page?
page1: "lights"
page2: "camera"
page3: "action"
page4: "roll"
page5: "film"
I was thinking to have a main page one could always come back. So to change your example.
page1: "ligths"
page2: "camera"
page3: "Main"
page4: "roll"
page5: "film"
so
when on page 3:
Camera Main Roll
when on page2:
Lights Camera Main
when on page4:
Main Roll Film
But reading that and having played around now with the new blueprints I find it better to map
b[1] = Lights
b[2[ = Menu
b[3[ = Media
the menu obviously gives you a page selector.
missing now only is an automation to display the status page (with time, temperature etc. after maybe 30 secs.
That would be the most versatile way I think.
Now for me the only missing puzzle piece is the nightmode switch. I will check if I can hack your idle blueprint. I basically just need an automation to change the idle timeout from some secs to -1.
A simple solution would be to send the Nextion commands to your HASP via MQTT:
- service: mqtt.publish
data:
topic: "hasp/plate01/command/json"
payload: '["sleep=0","thsp=0"]'
Check out the thsp
command in the Nextion instruction set
I’ll still work on seeing if there’s a cool way to make this happen via blueprints, but it’s easy enough using an automation to send the Nextion commands you want directly.
Thats nice. but I also need "thup=1"
so it wakes up as well when touched.
so basically I could set the sleep timer when nightmode is turned on and I can disable it when nightmode stops. easy…