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?
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!
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.
Home Assistant Lovelace compatibility release
time_pattern to match documentationHome 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)
Run the deployhasp.sh script to pull down the updated automations using one of the guides below:
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.
Hey sorry man, that’s my fault for not including HassIO instructions. It’s almost exactly the same, try this:
cd /config
bash <(wget -qO- -o /dev/null https://raw.githubusercontent.com/aderusha/HASwitchPlate/master/Home_Assistant/migrate-hasp-107.sh)
Kicking around some ideas on how to handle the not-even-really-new-anymore Nextion firmware releases that bring AA fonts to the table.
One year ago I posted some details about the 0.55 (TJC-only) release and the nice anti-aliased and proportional font support that came with it. The problem at that time was the HASP project was just a little too big to fit into memory with that new release. Removing page 9 with the graph component and replacing it with a page suitable for climate controls appeared to be a working solution.
Since then, TJC has released a string of updates and Nextion has finally followed suit. The current 0.59 release not only supports AA fonts, but also UTF-8 encoded fonts. During this time, the new font format has been pretty well reverse-engineered allowing some advanced capability beyond what the native TJC/Nextion tools provide. One such capability is extending a font to include icon sets, which means we can now mix characters and icons in a single text field. I can see this being crazy handy and I’ve created several such fonts with the Font Awesome icon set included.
However, there’s once again a memory problem. With the releases supporting UTF-8, replacing page 9 isn’t clearing up nearly enough memory. Simply deleting pages only works if I delete pages 6-9, leaving a lot of handy page layouts being cut from the project which seems like it’s too much.
The major component left in the project which is consuming a lot of RAM is the QR code on page 0. Removing that one element allows me to include extended font sets, the page 9 climate controls, and everything else we have in the existing project. The QR code is notionally only used once during initial setup, and even then it’s kind of redundant as the pertinent info is already on the screen for the user to type into a phone or laptop. The QR just makes it easy to connect to the WiFi AP to handle the first-time config.
So, one option is to nuke the QR code and leave everything else the same.
Another option is to make the first-time setup slightly less secure. Currently, the HASP generates an SSID and password based on the ESP8266’s MAC address. This isn’t really secure as that MAC address is broadcast to anyone listening, and the algorithm by which the SSID/password is generated isn’t even trying to be secure (and is also open source so it wouldn’t matter if it was, as the seed is broadcast). So, given that this fake security doesn’t seem to benefit anyone, another solution would be to change the ESP8266 code to use the same SSID and password every time, then generate a QR code as a static image, then include that image in the project on page 0. This frees up memory, allows for the first-time setup to work as normal, while slightly reducing security (although not really), and also removing the ability to use the QR code component for other use cases. I’m not sure if anyone is really using that feature outside of first-time setup.
I’m kinda just typing this out to collect my own thoughts on the matter, but now that I’ve done so… Still not sure what to do.
Anyone have any thoughts on this to share?
I vote drop QR code and page 9
think the fonts out ways the QR code
What about this Idea
each page is save a its own file then user could “Import” the Pages they want to use
have a still have the
“HASwitchPlate.HMI” for user starting out as is of now
then
HASwitchPlate_blank.HMI
HASwitchPlate_P1.HMI
HASwitchPlate_P2.HMI
…
then you would load the blank and import the P1, P2 as the User wants
I agree with dropping Page 0 and Q code support
Some may be using page 9 but some useful weather replacement would be nice.