Lacrosse WS2500-19 brightness sensor

Post here about devices that are not yet or not fully supported

Moderators: rtenklooster, Voyager, BertB, Stuntteam

Post Reply
Message
Author
Rolo644u
Normal user
Posts: 1
Joined: 28 Jul 2016, 08:57

Lacrosse WS2500-19 brightness sensor

#1 Post by Rolo644u » 28 Jul 2016, 09:11

Hi, I'm building a LUX sensor based on the Lacrosse WS2500-19 brightness sensor protocol. I have used this info : http://www.f6fbb.org/domo/sensors/ws2500-19.php for the protocol. I'm pulsing the bit's as in the examples but RF-Link does not respond. This sensor is in the supported devices list so I was expecting it to work.
I have tested with TX3 timing and with WS7000 timing, both do not work. I have used this info for the timing : http://www.f6fbb.org/domo/sensors/index.php.
When looking in the development code I do see this sensor in Plugin_041.c but the type of sensors handled are Rain, Meteo and Wind, no Brighness type is returned.
Can any on confirm a working ws2500-19 sensor on RF-Link ? Thanks !

User avatar
Stuntteam
Site Beheer
Posts: 720
Joined: 27 Jan 2016, 16:46

Re: Lacrosse WS2500-19 brightness sensor

#2 Post by Stuntteam » 28 Jul 2016, 11:28

might have been solved already.. see pm
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8

ReMi
Normal user
Posts: 1
Joined: 08 May 2017, 18:32

Re: Lacrosse WS2500-19 brightness sensor

#3 Post by ReMi » 08 May 2017, 18:39

Rolo644u wrote: 28 Jul 2016, 09:11 Hi, I'm building a LUX sensor based on the Lacrosse WS2500-19 brightness sensor protocol. I have used this info : http://www.f6fbb.org/domo/sensors/ws2500-19.php for the protocol. I'm pulsing the bit's as in the examples but RF-Link does not respond. This sensor is in the supported devices list so I was expecting it to work.
I have tested with TX3 timing and with WS7000 timing, both do not work. I have used this info for the timing : http://www.f6fbb.org/domo/sensors/index.php.
When looking in the development code I do see this sensor in Plugin_041.c but the type of sensors handled are Rain, Meteo and Wind, no Brighness type is returned.
Can any on confirm a working ws2500-19 sensor on RF-Link ? Thanks !
I would like to use an arduino for emulating this Lacrosse WS2500-19 sensor , do you possible have some code i can use ?

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#4 Post by Ton_vN » 30 Jan 2020, 20:01

Perhaps not the most correct place for discussion for my setup, but at least here a discussion on implementation of the protocol for WS7000/19 respectively WS2500/19.

Since a few days a 'lookalike' of WS7000/19 (equivalent to WS2500/19) in test-operation in combination with RFLink_Gateway [version 46] providing data-output to Domoticz.

Not yet many observations, but it looks that
- at low lightlevel the readout displayed in Domoticz seems to be rather accurate
- for presently moderate & high lightlevels the readout in Domoticz seems off by a factor 10 (or even more), hinting to a scaling-issue.

Obviously as 1st element of the functional chain being checked that in the Sensor-Controller the data from the sensor MAX44009 is appropriately coded before transmission.
Following the transmission from the sensor then 2 elements in the functional chain that process the data:
- RLinkGateway
- Domoticz software.
Therefore the reason and/or the remedy for the scaling issue must be found 'somewhere' in the sequential operation of those 3 elements.

Looking in the data-protocol for WS2500/19&WS7000/19 and the links in the previous messages this difference might be attributed to the F-bits, used in the message to send the 'multiplier' Facteur [=F].
From the data-protocol I deduct that a kind of 'gear-shifting' takes place for the filling of the message:
Low lightlevel => the measured lightvalue xyz directly fits in the range of the 3*4 L-bits => translates into (xyz) with F~1 => output value = 1*(1*x + 10*y + 100*z)
Higher lightlevel => the measured lightvalue approximates 10*(abc) => translates for the 3*4 L-bits into (abc) with F~10 => output value = 10*(1*a + 10*b + 100*c)
etc.
Is this interpretation correct?
Within the range of the L-bit segment of 0 ~ 999, in that way still very high lightlevels can be reported, although with decreasing resolution for increasing lightlevels.
'Gear-shifting' provides following message-contents:
F=0 => Multiplier = 10^0 = 1 => values 0 ~ 999 Lux with resolution of 1 Lux
F=1 => Multiplier = 10^1 = 10 => values 0 ~ 9990 Lux with resolution of 10 Lux
F=2 => Multiplier = 10^2 = 100 => values 0 ~ 99900 Lux with resolution of 100Lux
etc.

Anybody with similar observations as described in the second dash of the second section?
With a 'real' WS7000/19 or WS2500/19, or with a 'look-alike'?
Reason & remedy known?

BTW, anybody having a good, clear description how the M-bit segment is used (or might be used, e.g. to calculate sunshine-hours)?
Last edited by Ton_vN on 31 Mar 2020, 10:21, edited 3 times in total.

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#5 Post by Ton_vN » 28 Mar 2020, 08:08

The communication between WS7000-19-'clone' and an original WS2500-receiver has been checked: looks OK
Domoticz most probably just shows what RFLinkGateway presents.
.
Last days with clear-blue sky and plenty of sunshine gave ample opportunity to check the operation of the 'chain' with WS7000-19 => RFLinkGateway => Domoticz.
Compared in Domoticz the readings by a colocated sensor type SI1145 (= upper graph) with the info from WS7000-19 (= bottom graph).
The graph from SI1145 is rather smoothly rising in the morning.
In the resulting curve at Domoticz for WS7000-19 it can be clearly seen that
- the line starts indicating the L-value (with F=0 => multiplier = 1)
- the line at the 1st threshold drops back to an L-value which is representative for L/10 ( at that moment should be with F=2 => multiplier = 10).
- that process repeats itself at the 2nd thresholdlevel for L/100 (& F=3 => multiplier = 100).
Looking at the numbers in both graphs, a resemblance can be seen between SI1145 and WS700-19-'clone'.
However, for F>0 the value shown for WS7000-19 seems to be lagging by a factor 10.
At this moment apparently the handling of some F-values is missing 'somewhere' in the interfaces & functions around RFLinkGateway & Domoticz
.
SI1145 Run_up in morning
SI1145 Run_up in morning
SI1145Lux_20200327 [640x480].jpeg (20.86 KiB) Viewed 10457 times
WS7000_19 Run_up in morning
WS7000_19 Run_up in morning
WS7000P19_20200327 [640x480].jpeg (23.94 KiB) Viewed 10457 times

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#6 Post by Ton_vN » 08 Jun 2020, 14:41

Stuntteam provided RFLink-firmware testversion v49.4
Running smooth, generating plausible outputvalues for lightmeasurement from my WS7000-19-Clone.

One more step forward!
With this emulation of WS2500/19 aka WS7000/19, under application of this updated firmware for RFLinkGateway,
Domoticz now gets the transmitted lightvalues as defined for that 433MHz-interface.
All combinations of F-values and L-values applicable for the practical light values!
My clone as input applies a sensor MAX44009, consuming very low power, combining an IR-sensor and Light-sensor to mimick the human eye, and
measuring with an ultra-wide 22-bit dynamic range from 0.045 lux to 188,000 lux.
An I2C-buffer makes the MAX44009 compatible with the 2*SHT31 which are part of the configuration.

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#7 Post by Ton_vN » 28 Oct 2021, 09:49

After upgrade of the firmware of RFLinkGateway and WS_Controller, the WS7000P19 was coupled to Domoticz via RFLinkGateway.
One year later looked at the year-graphs from Domoticz and surprised to see that apparently a clamping is taking place at light level of approx. 65kLux.
Any user of RFLinkGateway in conjunction with Lightsensor WS2500/19 or WS7000/19 seeing similar graph?
Obvious next question: where in functional chain Sensor > RFLinkGateway > Domoticz is this clamping happening?
At this moment difficult to check, because lightlevels too low till next spring to serve as input >65kLux.
WS7000P19_Yeargraph
WS7000P19_Yeargraph
chart_WS7000P19year_210927.jpeg (69.04 KiB) Viewed 3515 times
For reference/comparison the light-curve from my Tempest PWS over the period starting April 2021 in which the higher lightlevels occur, and clearly show.
Tempest_Yeargraph
Tempest_Yeargraph
chart_Tempest_year_210927.jpeg (75.9 KiB) Viewed 3511 times

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#8 Post by Ton_vN » 17 Dec 2021, 23:07

The proper solution is: research & test, finding the source of the problem and subsequent correction of related firmware.
However, it involves at least 2 elements (WS7000P19-Controller and RFLinkGateway) and bright light (> 100kLux) is needed for reproduction of the problem.

Not nice, but very pragmatic remedy for this 'problem' is following make-shift solution.

Basic approach:
If the electronic & software functions 'somewhere' in the functional chain cause the described clamping, then reduce the input at the sensor so much that no clamping occurs.
In this case it means that a real input of approx. 150kLux should result in a virtual lightlevel on the sensor of approx. 60kLux.
=> find an optical attenuation filter of approx. 2,5* and put as cover over the sensor
=> while getting actual lightlevels of 0 ~150kLux, the sensor will effectively 'see' 0 ~60kLux
=> multiply the resulting, reported value in Domoticz by 2.5* to reconstruct the entry-value

During earlier testing with firmware 0.0. a ;) deodorantroller-cap provided physical attenuation for a similar situation.
Is really try&error to find a suitable cap, because most caps deliver more attenuation and are not 'uniform' in all critical directions.
After finding a suitable cap the most difficult part of the implementation is to exactly determine how much attenuation from the cap:
you temporarily need a well calibrated light measuring device.

Considering the occurence of clamping I have time till next april to find a better solution ..........

TD-er
Core team member
Posts: 6495
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#9 Post by TD-er » 17 Dec 2021, 23:56

Maybe you can also try one of those ND filters.
Those have a known attenuation for light (on various wavelengths, but should be "neutral" to colors) which makes testing probably a lot simpler.

With your cap it is impossible to know the attenuation of light for a given wave length.
Also it could be that this spectral response may shift when the cap heats up.

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#10 Post by Ton_vN » 20 Dec 2021, 15:00

@TDer

Completely agreed, and reason/background for the italic text in line 3:
it is a practical circumvention of the problem of clamping, nothing better than that.
My feeling is that the proper solution is described in line 2 of my previous message, but that takes time ......

TD-er
Core team member
Posts: 6495
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#11 Post by TD-er » 20 Dec 2021, 16:22

If you want, I can also 3D print an adapter for you.
For example a simple clamp on the tube and on the other end a ring adapter for a filter ring.

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#12 Post by Ton_vN » 08 Jul 2022, 08:03

It took quite long time to get perfect weather for this test, but recently a few continuously very bright & very clear days gave opportunity to make 'unspoiled' loggings of the transmission for highlevellightdata from the WS7000-Controller towards the RFLinkGateway.
Analysis of the best logging made in the RFLinkGateway shows that 22nd of June later than 11:15 the pulse-pattern is telling that the level should be > 65klux,
but the RFLinkGateway 'shifts gear downward' and via Domoticz (as in the picture below) shows level below 65klux.
Apparently MSB present from the Controller, but missing in the data from RFLinkGateway to Domoticz.
.
Reported to RFLinkStuntteam, and now waiting for response.
.
WS7000P19 Highlightlevel
WS7000P19 Highlightlevel
WS7000P19chart20220622.png (99.68 KiB) Viewed 668 times

Ton_vN
Normal user
Posts: 252
Joined: 21 Oct 2016, 15:20
Location: Hengelo (Ov)/ NL
Contact:

Re: Lacrosse WS2500-19 brightness sensor

#13 Post by Ton_vN » 17 Jul 2022, 14:19

This weekend's bright, sunny, cloudless days with high light level invite for more testing, but first need response from the RFLinkStuntteam with firmware-update from v49.4, otherwise just 'repeat'.

User avatar
Stuntteam
Site Beheer
Posts: 720
Joined: 27 Jan 2016, 16:46

Re: Lacrosse WS2500-19 brightness sensor

#14 Post by Stuntteam » 18 Jul 2022, 23:44

It's noted but due to vacations it will take a while..
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests