Switching one of your plates over shouldn’t mess up anything with your existing install. What might be easiest would be to rename one of your existing plates, and then run through the process above starting at step 2. If everything goes sideways and you just want your old config back, revert the firmware and rename the plate back to what it was before.
When working on this next release, I started down the path of making the automations more flexible by piling on dozens more automations. Things were just getting out of hand, you aren’t kidding about that. The new approach should go a long way to cutting that down by an order of magnitude. I think you’ll like this new setup
Working on a mount for a 4.3" Nexion display. The idea is for it to fit inside an electrical box like the current one (using the existing back as a starting point). Would like to get people’s opinion on the size of the bezel on this. I can shrink it down some, but because of the connector on the back, to get it really tight, you would have to remove the connector and solder the wires onto the board. So what do you think of this? (Let’s see if the picture will upload. Haven’t done this in awhile)
I reduced the speed and so far no network problems. In retrospect this makes sense since I was lazy wiring this up. It’s just a bunch of wires and there’s other power supplies close by.
So trying to build the HMI for the 4.3" basic display and running into some memory issues, like running out of it. I have duplicated the HMI for the 2.4" display, which compiles fine. I exported the picture and fonts from the 2.4" HMI file and while the picture is the same size, the fonts are not. Some are larger and others smaller. The end results is I am over the available memory by 48 bytes on each page. Global memory on the 2.4" is 3548 but 3612 on the 4.3". This is where the problem seems to be. Any suggestions or ideas on how to fix this? I can get it to compile by deleting p11.
You’re at the mercy of extremely limited global RAM. The exisiting project is literally at the limit for the 2.4, there is not a single byte free. You can delete pages, remove objects, or go through and reduce the size of the text fields on each button.
Available Memory3584
Global Memory:3612
Total size of picture:61,274
Total size of font:2,832,089
Error:Page:page0 Error! Memory overflow:3612+20=3632
Error:Page:page1 Error! Memory overflow:3612+20=3632
So is the global memory the amount available or the amount that is needed?
Global memory is used mostly for the properties of objects set to global, which is literally every object we use due to how everything works. So, removing length on text fields will have a direct impact.
Page 11 has some changes in the next release and I have some ideas cooking that could make it pretty useful.
Okay. On page 0, I changed the maximum text from 128 to 73 and it compiles. Hopefully your changes to page 11 won’t break it too bad. Just seems strange that I am using more global memory when I used all the same text lengths as the original. Only difference is the size of the fields. Still not sure why the font sizes are different when they are the same ones.
Got the buttons to work. Forgot to have the display send the ID of the button. Going to try the enhanced display to get around the memory issue. Since it is not using the existing mount, the extra space for the battery won’t be an issue.
Thanks for the detailed report my man, you’ve just uncovered a problem that I can fix - if you’re starting w/ the new HASP firmware, but old Nextion firmware, and you haven’t yet configured WiFi, there can be a problem with the serial speed being reset because the old nextion firmware does that with every load of page 0.
I’ve made a change to the dev release which I think should address this. It’s a bit of a corner-case but I doubt I’d have run into it without the report. Thanks!
Looking at the instructions for deploying a HASP using the new blueprint stuff and one thing I saw was removing the packages directory. If I want to deploy a new HASP, do I have to also update all my existing ones?
For each HASP deployed under the existing codebase (not dev), there will be one folder under packages named to match your HASP device name. If you want to test with one of your HASPs, the easiest approach would be to rename the HASP (so it doesn’t match the name of one of your folders under packages), and then deploy blueprints pointing at that new name.
Once everything is released and you’re happy with it, you can delete the individual folder for each HASP under packages and Home Assistant will stop loading all the automations and entities contained in there.
Carrying on this set up from scratch, I set up from the access point and the hasp now connects to my home wifi. It also used MQTT to create a discovered device plate01.
However it now seems to have forgotten the MQTT settings. On the web page the MQTT details are blank, and no matter how many times I set them and click “Save Settings” in the web interface, they just don’t stick. Very frustrating.