With a new install, I see open weather map appears to be working - I thought they stopped the free key usage years ago? I put in one of my keys and it appears to be working?
If so, I will keep it. Is there a way to change temp from C to F? Unless other stuff changed, I recall there is no way to change windspeed from Km/h to MPH or rain from mm to inches?
I thanked you up front for the step by step listings. Thank you again. They never worked with my 16gb SD cards - never could get buster to even boot on 3 different cards. My 8gb card was too slow to bother with. I finally tried a 32gb card and got it to boot. Then I couuld add HG. So my days of delays was due to SD card issues.
Now that I got it to boot and install, it did take 3-4 hours to upgrade buster 8-20-2020 but it finally finished. So I have an HG only system. Now I get to try to make it work as well as before. That is proving very challenging also.
I took your advice and did not use a backup file and reprogrammed everything from scratch.
As before, HG refuses to accept my email credentials and thus I still have no email.
Today I again lost all security devices: HG refuses to acknowledge seeing them change states. They worked flawlessly with my old 8Gb system… I just unplugged and replugged in my CM15a and it began to see door sensors again. So I began to install them to the new 32GB system… got 5 of 8 to register then it went dead again on reading the remaining 3 security modules.
Thank you for the reminder on open weather. Unfortunately my version oif HG does not let me change degrees to F, mm to inches, or km/hr to mph. Perhaps I need to buy a European CM15a? I do not see how that would change HG not changing units… FYI, under settings, I can change my key, my city, my language, & my update time for weather. Under maintenance->userInterface, I can change C to F but it has no affect on the weather gadjet. So not sure why you can change these and I cannot…
Did you adjust the locales correctly in the RPI Configuration section.
HG does allow you to adjust Celsius to Fahrenheit in the Maintenance>User Interface section and those adjusted settings are universal across HG.
You really need to completely configure HG BEFORE you start installing programs. Delete the Open Weather program, make sure your system is set for Fahrenheit and reinstall the Open Weather program. BACKUP Before attempting any of this.
I firmly believe your LAN is not functioning optimally so the lag in your calls to the HG server is causing much of that strange behaviour.
Have you any other equipment attached to your LAN that may be causing this.
I do suggest you invest in a RPI3b+ some new SD cards, 16gb or better.
Now that you have all the copy/paste instructions to get RaspberryOS and HG installed and know your way around the Raspberry Pi Configuration tool you will be able to install a new setup on a new SD card on a RPI3b+ quite easily.
Bear in mind that most modern software expects that you have a fairly decent bandwidth so maybe at some stage if you got to try an installation on something half decent you will definitely see a general performance increase in HG.
I’m wondering if those corrupt Configuration files are happening due to delayed writes to your SD card and you are navigating away from the file before the write operation is complete.
locales set to ‘all.’ next page gives 3 choices, none en-us utf8 so i leave it none as lots of online help says to do. no matter what i pick it sets it to:
Generating locales (this might take a while)…
en_GB.UTF-8…
I told u HG lets us set C or F - why do you repeat it like it is news? That does not change weather temp from C to F. of value would be a comment that says ‘my weather reads temp in F’ or ‘you’re right, weather never changes from metric units in hg.’
completely config hg b4 adding programs? are you aware hg comes with some built in programs? like open weather? so that suggestion does not work.
i certainly could move to downtown manhattan ang get 5g, then my speeds would be faster. that is not helpful comment. my lan is what it is and runs 100 or 1000mb/s in routers and such. my internet speed is of no concern to the hg workings inside my lan.
delayed writes because i am not waiting on the commands to finish? when i change something i wait for it to finish and say saved etc. not an issue.
The issue with open weather not displaying F was reported by me and lostdog several versions ago. I posted how to fix this issue on github as well a few other issues with the widget and program.
Fine. I’ve given you all the advice I’m giving at this stage.
You have what you need to install a fully functioning version of HG and as @Halr stated he managed to install a fully functioning HG setup following these instructions.
I’ve zero interest in Open Weather three day forecasts as I see no benefit in it from an automation perspective. At best the data is selected from random locations and is totally arbitrary. If you feel you need this function in your setup you should dig a little deeper in the HG GitHub for a solution.
I suggested using a faster broadband connection purely as a demonstration to see where your own install may be falling down. It’s entirely up to you what you choose.
You’ve got to put the research in to get things working in the open source world. I’ve done what I can do. It’s now up to you.
If you were using a RPi based on the original HW, it won’t boot current versions of HG. I just ran through a large number of combinations of HG, OS, and RPi’s and I was surprised by how many did NOT function. The common factor was original RPi HW with newer HG (1.2 and newer) with any OS. It’s possible some of this is related to mono versions but the end result was the same. I was able to get the RPi1 HW working with 1.1.500 with mono 3.2.8 on Jessie. Nothing newer worked on RPi1 (1B, 1B+, ZW). RPi2B, 3B, and 4B all worked just fine with all configs I tried.
It would be interesting to see how many still use the RPI 1 with HG. Even more interesting to see how many still use HG.
I think with the declaration the HG was a finished product development wise back in 2017 the 2 and 3 models were overlooked in so many different aspects as you well know. I reckon it will be down to the RPI4 to play catch-up at this stage.
For basic HG Configuration I’ve found the RPI3b+ to be acceptable with the latest version of RaspberryOS and HG 1.3 v19 so far but with your findings on the GPIO front and a number of other niggles I’ve discovered myself I’m wondering if these issues will ever be fully tested and the subsequent findings be ever implemented.
[quote=“Petediscrete, post:9, topic:651”]
You’ve got to put the research in to get things working in the open source world. I’ve done what I can do. It’s now up to you.
[/quote] copied & pasted
Thanks bkenobi. Yes, there appears to be compatibility issues as you found and point out.
I would just add that my ZW ver1.1 pi’s all act the same, and would not run (not even boot) the 2020-08-20-raspios-buster-armhf-full.img at all on any 16gb cards. Not even a chance to load HG yet. Just dead. Yet the particians looked totally identical with the same files as 8GB & 32GB cards that DID boot and run. My 8gb SD cards wrote the img at 6-8mb/s, the 32gb card @ 30mb/s.
For added reference, I was using 16gb cards with Stretch just fine!
So I might suggest that in your combination of tries, a 32gb SD card with above buster OS, WILL run the latest HG 1.3v stable19 as it does here. I am just stuck with a few quirks and kinks to work out that have been issues on all my HG installs.
I can’t comment on how sd cards play into this. I used a stack of cards ranging from 8-32GB and they all seemed to perform ok. If one card isnt working I would assume the card is bad and not that the size caused compatibility issues. That said, if the card were a big enough an older device might not be able to properly address it.
If the same card and setup were moved to another RPi type and showed working that would be an interesting finding. RPi4 is only compatible with Buster so loading a Stretch image will not work.
It works across multiple platforms and should help improve your chances of transferring a downloaded image to an SD card that will successfully boot.
One of the biggest causes of a non booting RaspberryOS SD card is a bad file download from the Raspberry Pi Foundation’s repository. This coupled with the corresponding extraction of that Zip file all adds up to a non booting SD card. A respectable download speed generally helps to prevent this.
The constant reformatting of SD cards and the swapping back and fourth between the card reader and the RPI card slot doesn’t help either.
One of the most important goals is to identify a supplier of genuine SD cards. The marketplace is awash with counterfeit SD cards and yes even Amazon unwittingly have them advertised on their portal.
No card size is better than another. I can happily operate HG on a 16gb card. The trick is to avoid unnecessary writes ie constant HG logging will do nothing for the lifetime of an SD card.
Summing up from my experience, a RPI3b+, a decent power supply, a genuine SD card 16gb or greater with a properly imaged SD card and a decent bandwidth from your ISP are all you need for a reliable HG setup.
Thankfully this very handy utility takes a lot of heartache out of the whole faulty/fake SD card situation. I’ve successfully identified fakes with it and it does a really good job repairing known genuine cards. Definitely worth your while installing it https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html