Recent Posts


Fedora 24 and weexd Weather software

By Dale Reagan | July 17, 2016

I recently upgraded to Fedora 24 Workstation.   I typically start my Linux builds with a ‘live’ image and then add what I need/want, including things that you might normally only run on a ‘pure’ server.  Note that I do NOT suggest doing this for any system that is ‘on the Internet’…. 🙂  Among the issues I encountered were getting the weather software Weewx to work while running as a local user, AND, as a daemon process (auto-start on boot-up.)

Weewx is a well documented Python solution with active development.  In a future post I may explore it further; in this post, I am focused on the problems I encountered and solutions I found for these problems.

A reminder –  as with many ‘resources’ you find on the web, it is easy to be mis-directed when problem solving – if you stay close to your ‘errors’ and close to your problem descriptions then you should be able to resolve the issue yourself;  unless you get lucky and the first ‘I solved this’ post you encounter gets things working (usually, without really explaining how the ‘solution’ resolves the issue [see my post about ‘Airprint’ issues.]

First Problem – installing ‘missing’ software

# required packages - most of this from the Weewx docs
 sudo pip install configobj
 sudo pip install Cheetah
 sudo pip install pillow

# required if hardware is serial or USB:
 sudo pip install pyserial
 sudo pip install pyusb

# optional for extended almanac information:
 sudo pip install pyephem

### if errors w/reports you may need to add these (not in the docs)
 sudo pip install image

Second problem – Weewx local user USB Device access

If you are directly connecting your USB weather station, then one custom Udev rule may work for you.  If, however, if, like me, you are using an ‘external’ USB hub connected to your Linux system, and then connecting your USB weather station to the external HUB you may need to create TWO udev rules: one for the eXT HUB and one for the WX device…

Example custom Udev rule (your setup will most likely VARY…) allowing ‘group’ access to the devices. (i.e. create/edit file: /etc/udec/rules.d/70-persistent-YOUR_DEVICE)

## rule for the 4-port-hub - using 'plugdev' group 
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="2046", GROUP="plugdev", MODE="0660", LABEL="4-port-hub_wx"
## rule for Acturite weather station
SUBSYSTEM=="usb", ATTRS{idVendor}=="24c0", ATTRS{idProduct}=="0003", GROUP="wx-user", MODE="0660", LABEL="Acurite_Wx

Note: you may need to create new 'groups' for the above, i.e. 'plugdev' and 'wx-user' or whatever you use. Once groups are created you then need to add users to the group(s).  MODE 660 ~= read/write access for the device 'owner' (usually 'root') and for the group you specify...

Third problem – installing weewx as systemd ‘service’

The Weewx example ‘service file’ did not work for my FC 24 install (~/weewx/util/systemd/weewx.service).  However, with a few tweaks it is now working well.

I installed a ‘missing’ service, and edited a ‘mismatch’ service name in the example file:

# install ntp, configure, enable and start – missing from my FC 24 install? (perhaps due to the ‘spin’ that I started with…)

dnf install ntp
# check/modify config for ntp and then load, enable, start, check
systemctl daemon-reload
systemctl enable ntpdate.service
systemctl start ntpdate.service
systemctl status ntpdate.service

# modify /etc/systemd/system/

change ‘ntp.service’ to ‘ntpdate.service’

So, BEFORE working on the systemd config, I was able to start Weewx as daemon from the command line – so I knew that it should work – still, systemd was complaining… The error message that I was getting from the systemctl command ended with:

(code=exited, status=203/EXEC)

Ok, first try at searching for something like:  weewx systemd 203/exec;   search results were somewhat helpful, but did not lead to a solution.  The documentation for systemd was also not helpful, until I ‘thought about it’…  The fix for me – modify the file – tweak the Systemd ExecStart command to INCLUDE the path to Python (or whatever other command you are trying to get working; seems that shebang lines are ‘ignored’ by Systemd?), i.e.:

ExecStart=/bin/python /WEEwxd_Path –daemon –pidfile=/PID_Path/  /Weewxd_CONF_PATH

On a typical install, the above would be something like:

ExecStart=/bin/python /home/weewx/bin/weewxd –daemon –pidfile=/var/run/weather/ /home/weewx/weewx.conf

Once above changes were made, then ‘tell’ systemd about the updates and start the service, i.e.

systemctl enable weewx
systemctl daemon-reload
systemctl start  weewx
systemctl status weewx

Now check for syslog entries and updated web pages (generated by Weewx.)

Of course, your mileage should vary – good luck! 🙂

Topics: Computer Technology, Hardware, Problem Solving, Sensors, Unix-Linux-Os | Comments Off on Fedora 24 and weexd Weather software

Apple Airprint with HP OfficeJet Pro 8600 – solved

By Dale Reagan | September 27, 2015

This appears to a be a common problem (based on all the web twists and turns I took trying to resolve it.) If you are in a non-Apple environment then printing from an iPad to a NON-Apple printer or with a NON-Apple wifi setup can be a journey to get working…  Suggestions included:

Side note – Airprint appears to send everything as a PDF document to an endpoint; the endpoint (printer) then ‘interprets/renders’ the PDF; it is very ‘slow’ and there may be limited OPTIONs  for managing the printed output (i.e. may not be able to change layout, turn color ‘off’, etc. – at least in my case I can select page print ranges and B&W only printing); you may want to adjust your ‘default print’ options (on the printer) if you do a lot of printing via Airprint…

Other problem symptoms – after you get the first working print job going – time passes and:

Both of the above show up frequently in Internet searches on both Apple and HP support sites; many suggestions point you to reset/re-power everything – that may get things working but is not a real solution.  If may have to ‘dig a bit’ and go through some trial and error approaches since ‘all of the pieces’ are not clearly explained (at least I did not encounter and end-to-end document that explains how this *should* work or how to *get it working*…)

I arrived at this solution by getting enough background on what protocols Airprint uses to correlate them with services that my printer supports (in my case, it appears to be IPP and Bonjour.)  Along with that (at least at this time) I also adjusted my router and ‘turned off’ Enable Multicast Streams.

HP OfficeJet Pro 8600 – steps & settings

Airprint with HP Printer Setting/changes that worked for me

This is what gets Airprint working on the HP OfficeJet Pro 8600:

What’s causing this intermittent success with locating a Bonjour Printer?

Some guesses:

Other possible solutions

Firewall note – based on other web postings, I tried various SPI-Firewall related settings – this made no difference for me (i.e. Endpoint filtering is set to  ‘Port And Address Restricted’.

On my printer (i.e. this may be different on YOUR printer, but look for similar options), the URLs to the above are:

make a backup BEFORE you start tinkering...

# Master ‘Service’ Toggle

# Bonjour

# Internet Printer Protocol

Probably not Relevant since is the firewall ON the PRINTER, but including since this is what I have:

 https://YOUR_HP_8600/index.html#hId-advOptPage ## Firewall Options

Firewall Enabled options:

Additional notes – 8600 Printer Service Ports

If you cannot see your printer the confirm that the ports being used are ‘open for traffic’ on your network, i.e. for AirPrint on the 8600 (or similar) printer, you probably need to allow traffic on at least these ports: 515, 5353, and 9100.


Name Protocol Service Type Printer/MFP Port Remote Port
Bonjour UDP Printer/MFP Service 5353 Any
Bonjour UDP Remote Any 5353
CIFS TCP Printer/MFP Service 445 Any
DHCPv4/BOOTP UDP Remote Any 67
DHCPv6 UDP Remote Any 547
DNS UDP Remote Any 53
HTTP TCP Remote Any 80
HTTP TCP Printer/MFP Service 80 Any
HTTP TCP Printer/MFP Service 8080 Any
HTTPS TCP Printer/MFP Service 443 Any
ICMPv4 ICMPv4 Printer/MFP Service None None
ICMPv6 ICMPv6 Printer/MFP Service None None
IGMPv2 IGMPv2 Printer/MFP Service None None
LLMNR UDP Remote Any 5355
LLMNR UDP Printer/MFP Service 5355 Any
LPD TCP Printer/MFP Service 515 Any
NetBIOS UDP Printer/MFP Service 137 Any
NetBIOS UDP Remote Any 137
NetBIOS UDP Printer/MFP Service 138 Any
NetBIOS UDP Remote Any 138
NetBIOS TCP Printer/MFP Service 139 Any
P9100 TCP Printer/MFP Service 9100 Any
SLP UDP Printer/MFP Service 427 Any
SLP UDP Remote Any 427
SMTP UDP Remote Any 25
SNMP UDP Printer/MFP Service 161 Any
Syslog UDP Remote Any 514
WS Discovery UDP Printer/MFP Service 3702 Any
WS Discovery UDP Remote Any 3702
WS Print TCP Printer/MFP Service 3910 Any
WS Print Eventing TCP Remote Any 5357

As always, your mileage may vary, but, hopefully you will find this as a working solution – and, find it in a few minutes versus the amount of time that I spent getting to an almost-working solution…

Topics: Computer Technology, Hardware, Problem Solving, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Apple Airprint with HP OfficeJet Pro 8600 – solved

Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station

By Dale Reagan | September 7, 2015

Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station Using a Wifi AP

Soooo, how can you capture the data from *your* WS-1000 and save it locally using the Wifi connection?

 Capture Wifi data from this unit requires some level of ‘hacking’…

Man-in-the-middle solutions

Re-configure the WS-1000

Setting up a WiFi Access Point

The goal is to put the pieces together that can:

Note about other options where you could do most of what is described in the next section if your router provides the needed options, i.e.

Components needed to provide Wifi AP Service

For my first pass I am using:

Once each of the above components are working then you simply (in theory…) connect the WS-1000 to your new AP and all traffic is sent to your server of choice via man-in-the-middle type tinkering.  Essentially, your AP will need to be configured such that it ‘tells’ the WS-1000 that your server of choice (i.e. my local Linux server) is really; the WS-1000 then ‘sends’ the data to your local server where you capture/log it.  And yes, you could do this for any device connecting to your custom AP (when this is done in a ‘public place’ (i.e. a coffee shop) then *your data* or perhaps even your web-connected-device could be compromised; avoid such connections if possible…)

I have not mentioned how to ‘capture’ the data  that the WS-1000 will be sending – the simplest solution:

  1. create a URI using the same ‘path’ that the WS-1000 is already using
  2. create a web page with PHP code to capture/log/massage the data
  3. create a script/process to ‘publish’ the data out to the Internet (you could combine that with step 2 but it is probably ‘better’ to use a secondary process, otherwise the code will become more complex – I prefer simpler solutions…)

You can ‘figure this out’ via any network ‘sniffing tool’ (i.e. WireShark.)

Of course, your mileage will vary – and perhaps, you may have a simpler solution.  🙂



Topics: Computer Technology, Hardware, Problem Solving, Sensors, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station

Part 1: Getting Data from Ambient Weather WS-1000 Wireless Weather Station

By Dale Reagan | August 15, 2014

This is my second Ambient Weather station solution – the ws-1090 console still works but the remote sensors faded away after ~2 years…

The web page for the Ambient Weather WS-1000 personal weather station (PWS) lists quite a number of features (see below.)  I either mis-read the information OR based on a lack of adequate information I assumed that I could ‘point’ the ‘upload’ to a server of my choice, i.e. this server.  It seems that the version that I have does not permit this – it will only upload to Wunderground.  There’s nothing wrong with that – except that I want to store the data locally as well as massage it a bit, i.e. the default upload includes inside temperature and humidity.  Also, I have other sensors that I might want to incorporate (i.e. soil temperature, etc.)

While the ws-1000 does provide a means to ‘backup’ your data (via SD card) it is a manual process, and, it is ‘all data’ at once. There are no options for scheduled backups to the SD card (i.e. once per day/week/etc.)  If you don’t manually backup the data then your data could ‘go missing’.  It is not clear (to me) whether the unit has some sort of internal battery (it is not listed as a ‘feature’), but, the unit does seem to ‘retain’ it’s settings during power-cycle or if you remove and re-attach the power supply.  [Side note – the power supply connection on my unit is ‘quirky’ – the console will experience power-loss while I hold it in my hand and fiddle with the settings; my solution was to tape the power connector in place…]

Soooo, how can you capture the data from *your* WS-1000 and save it locally using the Wifi connection?

 Capture Wifi data from this unit requires some level of ‘hacking’…

Man-in-the-middle solutions

Re-configure the WS-1000

Setting up an Ethernet/Wifi ‘Tap’

Setting up a network ‘tap’ is not very complicated but it does require:

tcpflow -i eth5  ## creates a NEW file for each 'flow'
tcpflow -i eth5 -c ## sends all output to the console/screen
tcpflow -i eth5 -C | tee -a /some_folder/your_desired_log_file.log ## send to ONE log file
tcpflow -i eth5 -C  dst host | tee -a /some_folder/your_desired_log_file.log
## above - only saves/captures data sent to specified host:

While using tcpflow works it is a manual approach (yes, you could automate it via scripting and server configs), but, of course, I would prefer an automated solution.  Since this is still a work-in-progress I will update when I get the WiFi AP (access point) solution working.

Ambient Weather WS-1000 partial feature/info list: Features:


Topics: Computer Technology, Hardware, Problem Solving, Savannah Georgia (USA), Sensors, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Part 1: Getting Data from Ambient Weather WS-1000 Wireless Weather Station

ZSH: Simple Network Port Checker

By Dale Reagan | April 19, 2014

Ok, I had an itch – I prefer to use what I deem ‘simple’ tools to get things done – in this case I needed a simple solution for checking for open ports (i.e. port traffic is not blocked by a firewall.)  After a quick scan of the ZSH man pages I found:

Simple use of these functions is, well, simple.  I’ve become fond of ZSH after working with it for a few years – and this relative simplicity continues to entice me.

From the man zshtcpsys page: To use the system where it is available, it should be enough to ‘autoload -U tcp_open’ and run tcp_open as documented below to start a  session.

Ok, the simple sequence is:

  1. load TCP module
  2. open a tcp session
  3. close the session

Sample script:

autoload -U tcp_open
tcp_open localhost 80

Ok, if you run the above there is delay after the tcp_open command.  I prefer a quick response so shorten this to:

T_MSG=$(tcp_open localhost 80)

By ‘wrapping things up’ the ‘tcp_close’ is done for you (the tcp_close command, if still present, will announce that there are no open sessions to close…)

So my simple script becomes:

## load the required ZSH functions
autoload -U tcp_open
## capture the text output AND standard Error output from tcp_open
T_MSG=$(tcp_open ${HOST_TO_CHECK} ${PORT_TO_CHECK} 2>&1)
E_STAT=$? ## capture the 'result code' from the previous command
## print a summary, and remove extra lines from ${T_MSG} results
printf "${HOST_TO_CHECK} | ${PORT_TO_CHECK} | ${E_STAT} | ${T_MSG}\n" | head -1

Simple enhancements – add some print formatting:

printf “${HOST_TO_CHECK} | %5d | ${E_STAT} | ${T_MSG}\n” ${PORT_TO_CHECK} |

Save the above as /tmp/chk.port.zsh (adjust path to zsh if needed and chmod 755) and try:

for PORTS in 22 23 80 443 ; do /tmp/chk.port.zsh SYSNAME ${PORT} ; done

You should get something like:

Test_host | Port    22 | 0 | Session 1 (host Test_host, port 22 fd 3) opened OK. Setting default TCP session 1
Test_host | Port    23 | 1 | tcp_open:ztcp:174: connection failed: connection refused
Test_host | Port    80 | 0 | Session 1 (host Test_host, port 80 fd 3) opened OK. Setting default TCP session 1
Test_host | Port   443 | 1 | tcp_open:ztcp:174: connection failed: connection refused

We can clean this up a bit more by removing repetitive messages/info, i.e. with an update:

printf "${HOST_TO_CHECK} | ${PORT_TO_CHECK} | ${E_STAT} | ${T_MSG}\n" | head -1 | \
   sed -e 's/tcp_open:ztcp:174://g'"

“Wait, Wait!”, you say… “Isn’t tool XYB ‘better’ for port checking?…”
Hmm, perhaps, but the point here is that I can do ‘something’ by taking advantage of an existing resource without having to introduce yet-another-tool…

Some ‘enhancements’ you might consider would be to ‘paralellize’ this process, i.e. run N-background processes – this takes some tinkering but can speed things up quite a bit (but mind that you don’t consume all of your system resources!)

As always, I’d expect your mileage (and opinions) to vary – at least a bit. 🙂

Topics: Problem Solving, System and Network Security, Unix-Linux-Os | Comments Off on ZSH: Simple Network Port Checker

« Previous Entries

YOUR GeoIP Data | Ip:
Continent: NA | Country Code: US | Country Name: United States
Region: | State/Region Name: | City:
(US only) Area Code: 0 | Postal code/Zip:
Latitude: 38.000000 | Longitude: -97.000000
Note - if using a mobile device your physical location may NOT be accurate...

Georgia-USA.Com - Web Hosting for Business