Weather Monitor II and wdisplay

Oldie but a goodie. I have owned a Davis WMII since 1998. Recently I’ve been concerned that the Windows 2000 that I have Weather Link on is probably going to die sooner than the WM, so I’m trying to migrate it to a newer linux laptop. I’ve tried to run wdisplay, but it appears that I’m just getting ‘0’ as data. I can run picocom and send a ‘LOOP’ command and get data back, so I know I have connectivity. I’m not sure if the unit is a pre-rev E or not, but I’ve tried it both ways. Is there some sort of debug option? The error log shows nothing. A also tried to run consolewd, but that’s apparently compiled for a 32 bit system and not 64.

is this the 64 bit Gui version of WD for linux?
I will need to check on my code for supporting the davis WII
(you are the first person I think to test)
there is a 64 bit version of consolewd

I did find one bug re getting data from a Davis WMII
so try the latest update

Thanks, yes this is the 64 bit version of WD for linux. I’ll check out the new version of wdisplay and look for the 64 bit version of consolewd. I thought there was just the one for linux and that (judging from the readme) looks to be made for the Raspberry PI

there is a 64 bit version of consolewd for the raspberry pi 3 and for a Linux 64 bit desktop

Okay, two things. I’ve downloaded the 64 bit versions of wdisplay and consolewd. When I run wdisplay, I get the same result as before which is nothing. Previously I was getting ‘0’ in the terminal window, now not even that. When I look at the debug log, it says that I’m opening the com port, but nothing after that.
I tried consolewd because I thought I might get some other info, but I’m hitting a wall there. I get:
owner@owner-ThinkPad-X131e:~/consolewdfiles$ ./
/home/owner/consolewdfiles/consolewd: error while loading shared libraries: cannot open shared object file: No such file or directory
owner@owner-ThinkPad-X131e:~/consolewdfiles$ ls /home/owner/consolewdfiles/deploy

I modified the script to print out LD_LIBRARY_PATH so you can see that it’s pointing to the deploy directory, but it’s not finding the file.
I looked at the executable:

owner@owner-ThinkPad-X131e:~/consolewdfiles$ ldd consolewd => (0xf7f47000) => /lib/i386-linux-gnu/ (0xf7ecd000) => ./deploy/ (0xf7ec9000) => ./deploy/ (0xf7ec5000) => ./deploy/ (0xf7c29000) => /lib/i386-linux-gnu/ (0xf7c23000) => /lib/i386-linux-gnu/ (0xf7a6d000)
/lib/ (0xf7f49000) => not found => not found

I copied libcom and libusbdll to /lib/i386-linux-gnu, but no luck.

Are those two files perhaps statically linked? I’m confused. There is no libusb in deploy (I assume I’m supposed to apt-get that) and no libhid

there is a readme with the consolewd
you need to copy the library files in the deploy folder to
using sudo cp

Yeah, I read the readme.txt and copied them there, in /lib, and in /lib/i386-linux-gnu. It doesn’t pick them up from any of those locations.

did you copy to /usr/local/
also try

but are you running the default rasberry pi OS?
or there might be a way to find out (i.e a command) where the default library seach path environement is your your setup

I’m not running on a raspi, I’m using consolewd64desktop.tar.gz, which should be for 64 bit desktops, right? Anyway, I figured it out. The problem is when you do a ‘sudo consolewd’ in the script. That wipes away any changes you made to LD_LIBRARY_PATH. If you just run ‘./consolewd’ it works… kinda;
Now to the next problem. If you get beyond that point, you’ll get an error for libusb. It appears that the program is still 32 bit, so it will fail because libusb-dev installs the 64 bit versions of the library. You can do this to fix that problem on ubuntu:
sudo apt-get install libusb-0.1-4:i386

Now I’m stuck with this error:
owner@owner-ThinkPad-X131e:~/consolewdfiles$ ./consolewd
./consolewd: error while loading shared libraries: wrong ELF class: ELFCLASS64

That’s because all I have are 64 bit x86 and ARM versions of this library (the later was from when I installed the wrong Raspi version.):

/usr/lib/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=918916164d292d242056269f94b3551f308d7b4c, not stripped
/usr/lib/ ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=106c85678eaf51586d8bfe8930f6aa2e274cd53f, not stripped

Does anyone have the 32 bit x86 version of this library or can tell me where the repo might be. Doing an ‘apt-get install libhid (libhid0,libhid-dev,libhid0-dev…)’ show that there are no packages for it. The 64 bit version’s on my system, so something had to load it at some point.

I will re check the code for the desktop gui 64 bit version too for Davis WMII

I was able to find the source to and tried to build a 32 bit version. Unfortunately all I have is a 64 bit machine and when you do a ‘configure’ to build the makefiles, it assumes the architecture of the machine you’re running on. I’ve tried to force it to compile and load 32 bit, but I’ve had no luck.
If you have a x86_64 architecture available and can recompile your code so that consolewd64desktop.tar.gz has 64 bit rather than 32 bit binaries, that would be the far easier route.

I was able to get the lihid library to compile. I had to ‘hand walk’ the build by typing in the correct i386 library locations into the command that failed. For some reason that I was never able to understand, it kept wanting to add a ‘-L/usr//lib/x64’ into the linking rather than the 32 bit . I had to install the 32 bit version of libusb.a, which removed my 64 bit version. When I got the library built, I switched it back. Anyway, I am getting data, but it;s not right:

Current data : Temperature= 30.2 Windspeed =0.0 Gustspeed =2.0 Direction =0 Humidity=100 Barometer=31.5 Daily Rain=0.0

Some of the data looks more or less right. Temperature is wrong, even if it was Celsius (checked the config, it was not) and bounces between 30 and 80. LIkewise Humidity bounces between 100 and something like 15

its not clear what version you are now running to get data?

Listed on the site as “Weather Display for Linux console 64 bit Linux desktop Version on 27 May 2019 - 22:12:35”

OK, so its working a bit…but getting out of sync by the sounds of it
I will check the code
and check on library files too

re the 32/64 bit of the deploy files
objdump -f | grep ^architecture

says its 64 bit (and same with all the other library files in the deploy folder

That’s at least not what I’m seeing:
wner@owner-ThinkPad-X131e:~/consolewdfiles/deploy$ file ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
owner@owner-ThinkPad-X131e:~/consolewdfiles/deploy$ objdump -f | grep ^architecture
architecture: i386, flags 0x00000150:

Okay, redownloaded again and I concur that it’s 64 bit and the libs are 64 bit. it’s running, but there still seems to be a couple of issues:

ser_read : Entering
ser_read error Resource temporarily unavailable
Read size -1 :
ser_read : Exiting
Write size 7 : 4c 4f 4f 50 ff ff 0d
ser_read : Entering
Read size 19 : 06 01 fe 02 25 03 00 5f 00 bb 4e 30 7b 4f 04 00 00 48 bc
ser_read : Exiting
*****Received count = -----------------------------> 19
Current data 10:20:41: Temperature= 78.7 Windspeed =0.0 Gustspeed =0.0 Direction =95 Humidity=100 Barometer=29.9 Daily Rain=0.0 Rain Rate 0.0mm/min
ser_read : Entering
ser_read error Resource temporarily unavailable

The temperature is close at least, the monitor console shows 80. The humidity is way off (45% on the consoe). I’m not sure if the “error Resource temporarily Unavailable” is a feature of debug or not. I’m getting a lot of them, but the code is writing and getting data back

re the humidity
check what you have set as the humidity offset maybe in the config.txt?

I could add some debug code around that