WMR918 Init Issues

[hpux735]

I've spent a while debugging wview with my WMR918 station, and I've
discovered some interesting behavior. It's a bit of a long story, so
bear with me. First, I noticed that I got these "WIND packet..." type
messages in my /var/log/messages file all the time. They were driving
me nuts. I tried to turn them off through the verbosity setting in
the configuration, but that didn't work. I even tried sending SIGHUP
to the wviewd process, and that didn't work either. While I was doing
all this debugging, I noticed that wviewd never gracefully shutdown,
to the point that I added a test to the init script to test if it
still hadn't shutdown and if it didn't it would kill the process and
remove the pid file. I did some digging in the source and discovered
that the WMR918 initialization doesn't finish until it's seen a packet
from each of the rain, wind, internal and external sensors.
Apparently, my external sensor isn't being processed properly as an
"external temperature sensor" (which I'll get to in a bit) so it never
finishes. During the initialization it prints those packet messages
regardless of your setting. I modified the source in wmr918protocol.c
so that during the init process it only posts a message to /var/log/
messages the first time it receives a given protocol type, and prints
the ones it's still waiting for. Also, in the while loop, it checks
if the shutdown message has been received. If it has, it allows the
process to gracefully terminate. The patch is in the files section
(it should work with 5.4.0):

http://groups.google.com/group/wview/web/wmr918patch.diff

About the external temperature sensor, I had written a program that
decodes the wmr918 protocol, and I noticed that my station does
provide a external temperature packet, it isn't the exact one that
this code is expecting. My station is providing the thermohygrometer
reading, not the thermohygrobarometer reading it's expecting. If
someone knows the architecture of this part of the application pretty
well, help would be very much appreciated. I don't quite have the
time to learn all the ins-and-outs of how that code works right now.
I can provide raw serial capture data and a good protocol reference if
it helps. Even if you can give me some pointers on the architecture
of the code, it would help.

Thanks!
hpux735

[Mark S. Teel]

See below.

hpux735 wrote:
> I've spent a while debugging wview with my WMR918 station, and I've
> discovered some interesting behavior. It's a bit of a long story, so
> bear with me. First, I noticed that I got these "WIND packet..." type
> messages in my /var/log/messages file all the time. They were driving
> me nuts. I tried to turn them off through the verbosity setting in
> the configuration, but that didn't work. I even tried sending SIGHUP
> to the wviewd process, and that didn't work either. While I was doing
> all this debugging, I noticed that wviewd never gracefully shutdown,
> to the point that I added a test to the init script to test if it
> still hadn't shutdown and if it didn't it would kill the process and
> remove the pid file. I did some digging in the source and discovered
> that the WMR918 initialization doesn't finish until it's seen a packet
> from each of the rain, wind, internal and external sensors.
>

Yep, as designed.

> Apparently, my external sensor isn't being processed properly as an
> "external temperature sensor" (which I'll get to in a bit) so it never
> finishes. During the initialization it prints those packet messages
> regardless of your setting. I modified the source in wmr918protocol.c
> so that during the init process it only posts a message to /var/log/
> messages the first time it receives a given protocol type, and prints
> the ones it's still waiting for. Also, in the while loop, it checks
> if the shutdown message has been received. If it has, it allows the
> process to gracefully terminate.

Allowing the process to terminate is a good thing; the rest of your
changes are personal preference in my opinion. BTW, this whole init
process for WMR is discussed in the User Manual.

> The patch is in the files section
> (it should work with 5.4.0):
>
> http://groups.google.com/group/wview/web/wmr918patch.diff
>
> About the external temperature sensor, I had written a program that
> decodes the wmr918 protocol, and I noticed that my station does
> provide a external temperature packet, it isn't the exact one that
> this code is expecting. My station is providing the thermohygrometer
> reading, not the thermohygrobarometer reading it's expecting. If
> someone knows the architecture of this part of the application pretty
> well, help would be very much appreciated. I don't quite have the
> time to learn all the ins-and-outs of how that code works right now.
> I can provide raw serial capture data and a good protocol reference if
> it helps. Even if you can give me some pointers on the architecture
> of the code, it would help.
>

wmr918protocol.c: readStationData is the function that parses incoming
serial data.
> Thanks!
> hpux735
> >
>

[hpux735]

>
> Yep, as designed.

I had no doubt that's how it was designed :) I just thought I'd
explain where I was at.

> Allowing the process to terminate is a good thing; the rest of your
> changes are personal preference in my opinion. BTW, this whole init
> process for WMR is discussed in the User Manual.
>

I agree that's personal preference, I just got tired of seeing
hundreds upon hundreds of those packet messages. I couldn't really
keep track of the other things in my logs. I just thought I'd provide
them, in case you find them useful.

Also, I went back to the users manual looking for a description of the
init process because I don't remember seeing it. Could you provide me
a pointer?

>
> wmr918protocol.c: readStationData is the function that parses incoming
> serial data.
>

Right, so my question hinges on this part of the code:

FD_ZERO(&rfds);
FD_SET(work->medium.fd, &rfds);
if (select (work->medium.fd + 1, &rfds, NULL, NULL, &tv) > 0)
{
retVal = readStationData (work);
switch (retVal)

I'm not sure exactly what this "work" structure is, and where the
"wmr918Work.dataRXMask" bits are being set. It's easy enough for me to
add a "case WMR918GROUP2:" before the WMR918GROUP3 like you did with 5
and 6, but that won't help anything...

Thanks again.

[Mark S. Teel]

I can't find the description: I wrote it somewhere and must've lost it.
I'll add it for future releases. But you already know it now: The WMR9X8
initialization does not complete until the four basic sensor packets are
received.

If you can document the group 2 packet structure and corresponding data
for wview, I can add the support. Also, why are you receiving it instead
of the group3 packet?

Mark

[kcloy]

The group 2 packets were introduced in version 5.0.0 so they shouldn't
need to be added and the behavior described is normal except...

One of the things I've noticed while working diligently to keep my
WMR968 alive, which isn't easy, is that the supplied group 3 sensor
seems to give people a LOT of problems, myself included. In other wmr
related forum posts I've seen recommendations to replace the group 3
sensor with the group 2 sensors since it is said they actually work
better and some software allows the outside sensor to be selected. I
have no idea about that but did think about it when I saw the
wmr918Init code because for these folks wviewd would not allow
selectable primary outside temperature other than the default group 3
sensor.

long story short if hpux wants the group2 sensor to short-circuit the
Init process then this should be all that needs to be changed - that
is unless there really is a difference in hpux' group 2 packets:

if (select (work->medium.fd + 1, &rfds, NULL, NULL, &tv) > 0)
{
retVal = readStationData (work);
switch (retVal)

{
case WMR918GROUP0:
radMsgLog (PRI_MEDIUM, "received WIND packet...");
break;
case WMR918GROUP1:
radMsgLog (PRI_MEDIUM, "received RAIN packet...");
break;
case WMR918GROUP2:
case WMR918GROUP3:
radMsgLog (PRI_MEDIUM, "received OUT TEMP
packet...");
break;
case WMR918GROUP5:
case WMR918GROUP6:
radMsgLog (PRI_MEDIUM, "received IN TEMP
packet...");
break;
default:
break;
}
}

This of course is a one-off customization but probably the best option
would be to add a outside temp selection wmr918 option to the
config...

[kcloy]

Oh, since there are 3 group 2 channels any one of the 3 channels
could be the outside temp...

Also, hpux, if you do this modification and you transmit data to an
outside source you will need to make sure your customization puts the
group 2 channels's temp into the group 3 bucket that gets transmitted
to weather underground/CWOP/etc...

On Apr 19, 11:47 am, "Mark S. Teel" <mteel2...@gmail.com> wrote:

[Mark S. Teel]

Yes, I remember now. Problem with picking the Group2 instead of group3
is there is no easy way to know which of the channels should be used to
replace outTemp and outHumidity and which ones are "extra".

And the mod below does not get him past the init mask not being fully
populated, thus the system not finishing init.

Mark

[hpux735]

So, kcloy's customization gets you most of the way there... but it
actually takes a little more.

In the "readStationData" function, you can short-circuit the group2
packet into a group3.
This is because on a byte-by-byte level they are identical, except the
group 2 populates
a field that is ignored in group 3.

I've gone a head and implemented that change. Whether it works or
not, I'll let you know.

Thanks for the help, everyone!

[chaoschris]

Hi guys,
i guess i have the same problem like actually discussed here.
After installing the necessary packages on my debian 5 i compiled the
radlib and wview 5.3.2 sucessfully. After starting the daemon my cpu
utilization is going near 100% ( wviewd_wmr918 ) and nothing is going
on. In simulator mode everything runs fine and the simulated graphs
were created. The PHP-Webinterface tells me under the status tab that
wview is "starting", not "running" like in sumulator mode. In my case
i have only inside and outside sensors for temperature and humidity,
but no rain and windsensors.
Is this right that wview (combined with the wmr9X8) only runs when
there are all sensors and if so, is there any possible workaround? Is
it possible to continue the startup process when there is at least one
sensor? I'm no programmer and i am not sure if i will succeed with the
suggestions to modify the wmr918protocol.c given in this
thread.... ;-)

best regards
chris

[kcloy]

Correct, wview requires, at a minimum, the primary sensors be
available.

Unfortunately your configuration will require code changes since wview
is geared more toward a complete weather picture - and does it quite
well.

[hpux735]

It works! If you're interested, here is a link to the page:
http://alternet.us.com/wview/

[kcloy]

hpux,

I would be interested in hearing these results.

In version 4.0.1 of wview the group 2 sensors were treated the same as
the group 3 sensor. What that means is that version 4.0.1 might have
worked out of the box for people with just one outside group 2 sensor
but for me it would pick up my extra sensors (I have all three) as
outside temperature even though I had one in my attic. This resulted
in unusual readings when transmitting this data to CWOP/Weather
Underground/NOAA/etc since it would randomly transmit data from one of
each of the 4 available.

If you have a WMR968 you should be able to get this working great by
just making sure you are selecting the correct channel when populating
the group 3 data (there are 3). If you don't have a WMR968 I would be
interesting to know what you needed to change to make it work.

Thanks,
Kevin

> > >>> Thanks again.- Hide quoted text -
>
> - Show quoted text -

[kcloy]

Oh, I guess that answered my question before I even sent it...

[Matt Soffen]

There was a bug in the 4.0.1 code where it didn't properly store the data for WMR918GROUP2 .   It ignored the channel for the data and just stored the in the outside temp variable. 

Matt

[kcloy]

Actually, I know since I contributed the group 2 channel and pool
stuff so feel obligated to find out (and fix) if any of that is broken
in hpux' case...

> > > - Show quoted text -- Hide quoted text -

[mteel]

All of that is wonderful and good, but going forward, unless there is
a way to select Group2 channel 1, 2, or 3 or Group3 as the source of
outside temp and humidity, this all reduces to a discussion of hacking
methodology.

Mark

[kcloy]

I aggree completely and had thought about adding WMR sensor
selectability to the config but you are a coding daemon so it would be
hard to find a quiet moment in the life of wview to contribute this as
well.

[Mark Teel]

Do you mean daemon in the sense of:

No controlling terminal -or-
Typically runs with root privileges?

The quiet moments approach... feel free to add the configuration and corresponding code changes to utilize it. Just know it will require changes to the wviewmgmt web site that I will have limited time to make in the near future.

[kcloy]

In the sense that something keeps happening over-and-over without me
having to lift a finger...

[hpux735]

I suppose the ideal solution would be to add a field to the
configuration database for the selection of the outdoor temperature
group and channel. I don't know what all is required, I.e. adding to
the tables, but the changes to wmr918protocol.c should be minimal.
Ultimately, I agree that most of this discussion is related to the
best way to hack it together.

> ...
>
> read more »