That is the most annoying way to fix something… Still, glad to hear it’s working!
Guys,
Inspired by the metal frame @Gagan_Kochar showed us, I decided to get back on making a bigger HASP for my house.
The only thing I hate about Nextion is the viewing angle. When the nextion is the vertical, when you look from both sides the image seems ok. But when you look from the bottom up it’s terrible.
My 2.4inches Nextion is on the horizontal. Similarly, When i look from right to left it is ok. But when I look from left to right it’s awful.
Below are the pics of the same HASP from both sides.
Can anyone tell me if the 7 inches (or the 4 inches) Nextion has a better viewing angle when you look from the sides?
If not, does anyone managed to figure out a work around for this?
Thanks!
It’s entirely possible that the off-axis viewing on that panel is a relatively recent development as a result of quality fade from Nextion. Read more about that here.
Hate to say it, but the problem is back. 
Wow, that terrible… I had no ideia that was happening…
Well, i’ve always used the 2.4 and 3.5 inches… and they both had a terrible viewing angle.
I had a 4.5’’ laying around that didnt had time to use yet.
I just tested it and it’s viewing angle seems ok.
Here are the pics from both sides and the back (in case anyone wants to buy a similar one).
Thanks!!! 
Looks like we have a problem…
A little over a year ago Lovelace was introduced and while it’s pretty cool it’s missing some major functionality that’s used by HASP. I noticed this last February and raised a flag about it here.
Now, a year later, Lovelace is going to be mandatory and the result is that everyone’s HASP configuration is going to break. If you read through that thread you’ll find a lot of folks arguing that this is OK because there is technically a way to kind of do the same thing but only if you are manually editing YAML files to configure Lovelace.
Lovelace can be configured through the UI, or through manual YAML files, but doesn’t appear to allow the two methods to be mixed. I’m trying to figure out what the heck to do here in the 3 weeks we have left before HASP will no longer work with Home Assistant. To help guide that decision, I’m looking for input from you folks here.
How are you configuring Lovelace?
- Through the UI editor
- Through YAML files
- Still using “states” UI
- I have no idea what any of this means
0 voters
Well, i answered “through packages”, but I actually dont use the HASP packages.
I migrated and customized all the automations from the HASP package to my Automations.yaml
Ive been using Lovelace for several months along with HASP and everything is fine
I dont remeber exactly what there is in these packages… isnt It Just the automations and the “declarations” of the entities (input_booleans, input_numbers, etc)
Maybe one way out is to “force” users to copy/paste the content of the packages to their designated files (configurations.yaml, automations.yaml, etc)
I hope theres a way of keeping things simple, so more people are interested, using and making HASP better
The packages still work for everything except the UI elements, so no worries about the core HASP functionality. HASP will continue to work without the States UI, but the existing calls to create a view: are likely going to prevent Home Assistant from loading once they deprecate this functionality.
What we are after is a way to bundle together multiple groups and to do this in a way that works with the existing user’s configuration. As it stands, Lovelace can be configured by the user in one of two mutually-incompatible ways. I’m trying to figure out which direction to head because it doesn’t appear that we have a solution on the table which won’t break some of our user’s installations.
We’re now left trying to find the path forward that causes minimum damage.
I have only just started working on modifying the HASP for my needs so I probably don’t fully understand everything. I understand that when a new device is added, you want to include an example configuration for the user. But in starting my work, I’m going to have to modify the screens so most of the existing automation will not work and will have to be removed.
I’m not a big fan of how Lovelace (if it is Lovelace doing this), clumps everything together in the GUI Automation editor. I have about 4 of my own automation at this point and finding them in this list is a pain in the butt. I only have two HASPs, and that just saturates that list. I can see this would be a big problem for anyone with lots of automation even without a HASP. This probably isn’t part of the problem you are facing, but the GUI for automation needs to be able to group things together to make finding things easier.
I read through that thread you mentioned and didn’t really like the attitude of some of the responses. They were like “our way or the highway”. Was there any discussion about these changes being put into 107? Any engineering review? How it impacts existing installations? Removing functionality without a suitable replacement is just asking for a disaster.
I’m probably not expressing my feelings clearly, but bottom line is, I support the argument that what they are forcing onto the user base is not right and will cause unnecessary/unneeded problems.
I don’t know how hard it would be, but could the automation be moved into Node-RED (which would make have Node-RED installed required - but seems to be a standard item in almost all the HA tutorials I have seen)? None of the other devices I have added into HA have had the really nice installation that HASP has, so I am already used to editing YAML files for adding new devices and adding GUI items separately.
I’d strongly prefer not place yet another requirement for the users outside of Home Assistant itself, and it doesn’t directly resolve the issue at hand which is the ability to create a view in some univerally-applicable manner.
To be clear, I love Node-Red and I think it’s cool, but I also think it needlessly complicates an already-complicated solution and I’m trying to keep my support queue under control without adding something like NR to the stack 
I completely understand.
@luma a while ago there was a conversion tool that took an existing states UI groups file and converted it to the corresponding Lovelace YAML file. I did this and never looked back because it worked perfectly. I’ll use the frontend for configuring some integrations and such but I’ll never have the frontend manage my automation or Lovelace. I’ve been using HA for close to 3 years so I learned early on that if I wanted to do something, I had to modify the YAML whether that be the config, groups, automation, etc.
Understood, but it still creates a problem that Lovelace has bifurcated the possible user configurations out there. Creating a YAML is easy enough, but doing so requires the user to forego UI configuration.
the idea of posting the required yaml for the UI view to a text file or screen output so a user can just copy it to their lovelace yaml file, or paste into the Raw editor in the UI mode, seems like the best path to me (I have a switch plate that I have yet set up).
In general in HA folks are used to finding code, and pasting it. If it’s formatted and ready to go for the specific device even better!
1 Like
I just came to this forum to post my concerns for the things that are going to be retired very soon. I see you’re on it.
HASP v0.39 release
Home Assistant Lovelace compatibility release
Home Assistant Automations
- Remove “views” as they will be deprecated in 107
- Fixed automations utilizing
time_patternto match documentation - Changed weather provider to NWS as Met.no is no longer allowed to be configured manually
- Another MDI icon rename fix
- Update deployhasp.sh with some fixes for newer Home Assistant installations
- Added “migrate-hasp-107.sh” to automatically remove the “view” statements for compatibility w/ version 107
- Added example Lovelace YAML to replace some of the functionality lost from “view”
Fix for Home Assistant v107
Home Assistant is finally removing the “States” UI which has some unique functionality not present in Lovelace. In order to keep your configuration compatible with the new release, you can execute migrate-hasp-107.sh from your Home Installation directory to clear out the offending statements in your existing installation.
sudo su -s /bin/bash homeassistant
cd ~/.homeassistant
bash <(wget -qO- -o /dev/null https://raw.githubusercontent.com/aderusha/HASwitchPlate/master/Home_Assistant/migrate-hasp-107.sh)
Home Assistant Update Procedure
Run the deployhasp.sh script to pull down the updated automations using one of the guides below:
Links for more HASP info
- Main documentation page
- Buy HASwitchPlate PCBs - strongly recommended for safe assembly. Buy them from me or download the gerbers and send them to your favorite short-run PCB fab.
- Buy an assembled device ready to install if the build process seems intimidating
- HASwitchPlate Discord chat
- HASwitchPlate Reddit community
1 Like
I have three HASwitchPlates installed. The first part of this process under
Fix for Home Assistant v107 doesn’t work for my install. ( can’t find .homeassistant dir) I installed HA (Hassio) on a Ubuntu 18.04 i7 machine per HA’s recommended install process. I assume the problem is related to docker. Decide to stop as I don’t want to mess something up to require a fresh HA install.