profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ScottSturdivant/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Scott Sturdivant ScottSturdivant Denver, CO

ScottSturdivant/rpi_metar 19

METAR LED Display for a Raspberry Pi

ScottSturdivant/clint 1

Python Command-line Application Tools

ScottSturdivant/ansible 0

Model-driven configuration management, multi-node deployment/orchestration, and remote task execution system. Uses SSH by default, so there is no special software has to be installed on the nodes you manage. Ansible can be extended in any language. Note: The default branch is the development branch which many people run directly from checkout, if you need a stable version, see the release-XX branches, tags, or ansible.cc/releases.

ScottSturdivant/ansible-and-juliet 0

An ansible playbook to provide entertainment for a Mac-based computer lab

ScottSturdivant/crrr 0

Colorado Rhodesian Ridgeback Rescue

ScottSturdivant/crrr-devops 0

Ansible Scripts for CRRR

ScottSturdivant/cryptography 0

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.

ScottSturdivant/devops 0

Devops for home setup.

ScottSturdivant/eralchemy 0

Entity Relation Diagrams generation tool

issue closedScottSturdivant/rpi_metar

Allow duplicate LEDs not working

HI Scott,

I've come across an issue where I can't have 2 LEDs use the same airport code. It'll give this error

I realised that the code is meant to accept duplicates after reading the config readme and felt like an idiot so now I've edited this issue to reflect the new problem.

Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,738 - rpi_metar.airports - ERROR - 0.4 - metar_processor - YMAV1 has no data.
                                                       Traceback (most recent call last):
                                                         File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/airports.py", line 79, in process_metar
                                                           metar = metars[self.code]
                                                       KeyError: 'YMAV1'
Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,740 - rpi_metar.core - INFO - 0.4 - render_leds - got YBLT
Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,746 - rpi_metar.airports - ERROR - 0.4 - metar_processor - YMAV2 has no data.
                                                       Traceback (most recent call last):
                                                         File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/airports.py", line 79, in process_metar
                                                           metar = metars[self.code]
                                                       KeyError: 'YMAV2'

Will the code need to clip the number off the end of the airport code at some point to allow the sources to find it?

Thanks

closed time in 9 days

thommo17

issue commentScottSturdivant/rpi_metar

Allow duplicate LEDs not working

And there we go all fixed!

You're the best. Thanks for being so quick to respond too! Better than a lot of other IT support desks out there

Cheers

Matt

thommo17

comment created time in 9 days

issue commentScottSturdivant/rpi_metar

Allow duplicate LEDs not working

Actually just leave it with me for a bit because I think I need to make that change on my own fork.

I'll let you know.

Sorry

thommo17

comment created time in 9 days

issue commentScottSturdivant/rpi_metar

Allow duplicate LEDs not working

Hey Matt,

This functionality was added here: 93daefb

At least, I think that does what you're after! So, do:

YMAV1 = 27 YMAV2 = 28

Let me know how you get on!

Yeah I feel dumb because I read that and had to go change the whole topic.

Doing that doesn't work still.

Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,738 - rpi_metar.airports - ERROR - 0.4 - metar_processor - YMAV1 has no data.
                                                       Traceback (most recent call last):
                                                         File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/airports.py", line 79, in process_metar
                                                           metar = metars[self.code]
                                                       KeyError: 'YMAV1'
Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,740 - rpi_metar.core - INFO - 0.4 - render_leds - got YBLT
Feb 25 12:39:09 Australian-METAR-Map rpi_metar[13392]: 2021-02-25 12:39:09,746 - rpi_metar.airports - ERROR - 0.4 - metar_processor - YMAV2 has no data.
                                                       Traceback (most recent call last):
                                                         File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/airports.py", line 79, in process_metar
                                                           metar = metars[self.code]
                                                       KeyError: 'YMAV2'

any ideas?

thommo17

comment created time in 9 days

issue openedScottSturdivant/rpi_metar

Feature Request - Allow duplicate LEDs

HI Scott,

I've come across an issue where I can't have 2 LEDs use the same airport code. It'll give this error

Feb 25 11:53:16 Australian-METAR-Map systemd[1]: Started METAR Display.
Feb 25 11:53:21 Australian-METAR-Map crontab[32358]: (root) LIST (root)
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]: Traceback (most recent call last):
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:   File "/opt/rpi_metar_au/bin/rpi_metar", line 10, in <module>
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:     sys.exit(main())
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:   File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/core.py", line 346, in main
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:     cfg = load_configuration()
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:   File "/opt/rpi_metar_au/lib/python3.7/site-packages/rpi_metar/core.py", line 250, in load_configuration
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:     cfg.read(cfg_files)
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:   File "/usr/lib/python3.7/configparser.py", line 696, in read
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:     self._read(fp, filename)
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:   File "/usr/lib/python3.7/configparser.py", line 1091, in _read
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]:     fpname, lineno)
Feb 25 11:53:22 Australian-METAR-Map rpi_metar[32343]: configparser.DuplicateOptionError: While reading from '/etc/rpi_metar.conf' [line 17]: option 'ymav' in section 'airports' already exists
Feb 25 11:53:22 Australian-METAR-Map systemd[1]: rpi_metar_au.service: Main process exited, code=exited, status=1/FAILURE
Feb 25 11:53:22 Australian-METAR-Map systemd[1]: rpi_metar_au.service: Failed with result 'exit-code'.
Feb 25 11:53:22 Australian-METAR-Map systemd[1]: rpi_metar_au.service: Service RestartSec=100ms expired, scheduling restart.
Feb 25 11:53:22 Australian-METAR-Map systemd[1]: rpi_metar_au.service: Scheduled restart job, restart counter is at 217.
Feb 25 11:53:22 Australian-METAR-Map systemd[1]: Stopped METAR Display.

Is there a way we can have the configparser accept duplicates?

Or another way of setting up the config file? I already tried the airport code like this (YMAV = 27, 28) but it didn't work

created time in 9 days

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

Just letting you guys know that my fork is based off Australian METARs so it might suit you more. On Sat, 6 Feb 2021, 06:15 peterbickel, ***@***.***> wrote: Hi Scott, there is a misunderstanding. My problem has long been solved - as I wrote to you above. Your code suggestion for the airports.py worked. I marked it with a smile! I just wanted to give you the hint that the code does not work like this for all METAR. Outside the USA it leads to the fact that the visibility is reduced by the factor 1.609. So if you consider the numbers in the section get_flight_category as kilometers, they are not correct anymore. I adjusted this for me and also replaced the factor 1609 with 1000. Everything works perfectly. But you might want to make another change so that your code works all over the world. And to work all over the world it makes sense that the determination of the visibilities is done in meters, because that is the preferred unit internationally. My suggestion: Detect if there is a METAR with SM (NM) or meter. Set the factor for the conversion into kilometers accordingly. Comment the get_flight_category section so that the user assumes kilometers. If I had a little more know-how in programming I would do it myself, but unfortunately I can only make small changes - learning by doing. Translated with www.DeepL.com/Translator (free version) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMFBXY7KYHFQRW6AZU7DQCTS5RGV5ANCNFSM4W46TLTA .

Hi Thommo, your code looks fine. I just added some changes for a new version - it´s up to you if you like it or not.

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

Just letting you guys know that my fork is based off Australian METARs so it might suit you more.

On Sat, 6 Feb 2021, 06:15 peterbickel, notifications@github.com wrote:

Hi Scott, there is a misunderstanding. My problem has long been solved - as I wrote to you above. Your code suggestion for the airports.py worked. I marked it with a smile!

I just wanted to give you the hint that the code does not work like this for all METAR. Outside the USA it leads to the fact that the visibility is reduced by the factor 1.609. So if you consider the numbers in the section get_flight_category as kilometers, they are not correct anymore.

I adjusted this for me and also replaced the factor 1609 with 1000. Everything works perfectly. But you might want to make another change so that your code works all over the world. And to work all over the world it makes sense that the determination of the visibilities is done in meters, because that is the preferred unit internationally. My suggestion: Detect if there is a METAR with SM (NM) or meter. Set the factor for the conversion into kilometers accordingly. Comment the get_flight_category section so that the user assumes kilometers.

If I had a little more know-how in programming I would do it myself, but unfortunately I can only make small changes - learning by doing.

Translated with www.DeepL.com/Translator (free version)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ScottSturdivant/rpi_metar/issues/20#issuecomment-774264051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMFBXY7KYHFQRW6AZU7DQCTS5RGV5ANCNFSM4W46TLTA .

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

Hi Scott, there is a misunderstanding. My problem has long been solved - as I wrote to you above. Your code suggestion for the airports.py worked. I marked it with a smile!

I just wanted to give you the hint that the code does not work like this for all METAR. Outside the USA it leads to the fact that the visibility is reduced by the factor 1.609. So if you consider the numbers in the section get_flight_category as kilometers, they are not correct anymore.

I adjusted this for me and also replaced the factor 1609 with 1000. Everything works perfectly. But you might want to make another change so that your code works all over the world. And to work all over the world it makes sense that the determination of the visibilities is done in meters, because that is the preferred unit internationally. My suggestion: Detect if there is a METAR with SM (NM) or meter. Set the factor for the conversion into kilometers accordingly. Comment the get_flight_category section so that the user assumes kilometers.

If I had a little more know-how in programming I would do it myself, but unfortunately I can only make small changes - learning by doing.

Translated with www.DeepL.com/Translator (free version)

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

I just checked this and checked METARS over the whole world. It seems to be a specialty in the USA to indicate the visibility in SM. All other countries use meters.

Then it makes more sense to include a loop that executes the old code (divide by 1609) for SM and divides by 1000 for Meter.

Or what do you think?

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

First of all - the visibility in a METAR is aways in meter. To ensure that the string is reliably recognized this string is always 4-digit. To express the distance 10Kilometers and more, which is important for the evaluation of VFR conditions, the string 9999 is therefore used. CAVOK is a summary of visibility 9999 and cloud height greater than 5000ft above reference altitude. Therefore this is also assigned the value 10000 in an extra section.

Now back to the code... In the last section of wx.py the visibilities will be evaluated in km. Visibility = 8 means 8km = 8000meter So if you get the visibility from the metar with 8000 you have to divide it by 1000. If you divide it by 1609 you get the nautical miles - but these are NOT decisive for aviation in the visibility.

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

The code works fine and I get the definition for the categories now from wx.py. But I think I found an error in the code of wx.py.

The visibility from METAR is misinterpreted. Here is the official definition of visibility: Visibility = Reported in a four figure group (e.g. 0400 = 400 meters; 8000 = 8 km) up to but excluding 10 km; 9999 = 10km or more; 0000 = less than 50 meters visibility.

In the code of wx.py, the visibility from METAR is divided by 1609 (like nautical miles), but it must be divided by 1000 because it is always in meters.

Am I right?

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

Thx again for the try.... But the code has no effect - the only effect is alle LED´s will becoma dark :-(

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Individual thresholds for flight categories

Thx for the fast reply. Can you specify which lines I have to remove?

peterbickel

comment created time in a month

issue commentScottSturdivant/rpi_metar

Feature Request: Auto dim LEDs at night time to a lower value

It would be great to implement this. Everybody can adjust his own setting to the individual behavior of the LEDs.

tracehagan

comment created time in a month

issue openedScottSturdivant/rpi_metar

Individual thresholds for flight categories

I would like to adjust the thresholds for the color of the flight categories (VFR, MVFR, ...). I have found a section to do this at the end of wx.py. But the changes don't work because there seems to be another place where the categories are automatically taken from METAR. It doesn't have to be a solution in the configuration, I can adjust the code.

created time in a month

PR opened Absio/linvodb3-with-serialization-options

Bump ini from 1.3.5 to 1.3.8

Bumps ini from 1.3.5 to 1.3.8. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/ini/commit/a2c5da86604bc2238fe393c5ff083bf23a9910eb"><code>a2c5da8</code></a> 1.3.8</li> <li><a href="https://github.com/npm/ini/commit/af5c6bb5dca6f0248c153aa87e25bddfc515ff6e"><code>af5c6bb</code></a> Do not use Object.create(null)</li> <li><a href="https://github.com/npm/ini/commit/8b648a1ac49e1b3b7686ea957e0b95e544bc6ec1"><code>8b648a1</code></a> don't test where our devdeps don't even work</li> <li><a href="https://github.com/npm/ini/commit/c74c8af35f32b801a7e82a8309eab792a95932f6"><code>c74c8af</code></a> 1.3.7</li> <li><a href="https://github.com/npm/ini/commit/024b8b55ac1c980c6225607b007714c54eb501ba"><code>024b8b5</code></a> update deps, add linting</li> <li><a href="https://github.com/npm/ini/commit/032fbaf5f0b98fce70c8cc380e0d05177a9c9073"><code>032fbaf</code></a> Use Object.create(null) to avoid default object property hazards</li> <li><a href="https://github.com/npm/ini/commit/2da90391ef70db41d10f013e3a87f9a8c5d01a72"><code>2da9039</code></a> 1.3.6</li> <li><a href="https://github.com/npm/ini/commit/cfea636f534b5ca7550d2c28b7d1a95d936d56c6"><code>cfea636</code></a> better git push script, before publish instead of after</li> <li><a href="https://github.com/npm/ini/commit/56d2805e07ccd94e2ba0984ac9240ff02d44b6f1"><code>56d2805</code></a> do not allow invalid hazardous string as section name</li> <li>See full diff in <a href="https://github.com/isaacs/ini/compare/v1.3.5...v1.3.8">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~isaacs">isaacs</a>, a new releaser for ini since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+17 -5

0 comment

1 changed file

pr created time in 3 months

fork bmadr/rpi_metar

METAR LED Display for a Raspberry Pi

fork in 3 months