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
New 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: 786
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
New 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: 300
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: 300
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 16428 times
WS7000_19 Run_up in morning
WS7000_19 Run_up in morning
WS7000P19_20200327 [640x480].jpeg (23.94 KiB) Viewed 16428 times

Ton_vN
Normal user
Posts: 300
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: 300
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 9486 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 9482 times

Ton_vN
Normal user
Posts: 300
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: 8643
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: 300
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: 8643
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: 300
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 6639 times

Ton_vN
Normal user
Posts: 300
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: 786
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

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

Re: Lacrosse WS2500-19 brightness sensor

#15 Post by Ton_vN » 12 Dec 2022, 19:13

Summer vacation now probably forgotten.
;) Or interference from upcoming vacation?

Outdoors not much light available for testing, but might give time for testing of script-update as companion of some other update of the firmware.

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

Re: Lacrosse WS2500-19 brightness sensor

#16 Post by Ton_vN » 11 Jan 2023, 11:17

Er zijn zeker dringender aspecten om te verbeteren voor de RFLinkGateway-firmware, en de praktische lichtniveau's zijn momenteel heel ver beneden het 'probleem-gebied' > 65kLux, zoals ontdekt in firmware-testversie V49.4
maar dat geeft juist tijd om te kijken hoe voor deze correctie de firmware bijgewerkt kan worden, 'meeliftend' met andere aanpassingen.

Reactie wordt op prijs gesteld.

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

Re: Lacrosse WS2500-19 brightness sensor

#17 Post by Ton_vN » 08 Jun 2023, 18:15

Very clear sky today and nice spring weather is good for testing the readout for high levels of Light and UVI.
.
The graph below well demonstrates that the RFLinkGateway does not process the MSB of 65kLux for WS7000P19:
between today approx. 10:30 and 16:00 the graphline 'dips', although a level higher than 65kLux is expected,
Tempest-readout for comparison shows levels running up to 133kLux.
The sensor MAX44009 of WS7000P19 is also able to 'see' those values within it's technical range of 188kLux,
and therefore it would be nice if RFLinkGateway would correctly transfer the actual value.
Included in the next upgrade of the firmware for RFLinkGateway?
.
Comparatative Light-graph
Comparatative Light-graph
piVergelijk1Light230608.png (50.83 KiB) Viewed 4570 times

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

Re: Lacrosse WS2500-19 brightness sensor

#18 Post by Ton_vN » 25 Jul 2023, 10:27

A fix for this aspect to be included in upcoming upgrade R50?

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

Re: Lacrosse WS2500-19 brightness sensor

#19 Post by Ton_vN » 25 Aug 2023, 20:18

From 'repair' of the BH1750 in my DIY-setup now have a spare Dome for a BH1750.
In that DIY-setup have to calibrate/align the BH1750-with-dome and the TLS2561s:
that would provide data how much the dome is attenuating, and such data might be interesting to consider the spare dome as cap over the MAX44009.
First observation is that attenuation is approx. 3*
As makeshift interim solution pending a preferred upgrade of the RFLinkGateway's firmware,
it provides a practical (but inaccurate) range extension from max. 65kLux towards max. 195kLux.

For 2023 not an urgent matter, because the actual, practical values for 'naked' MAX44009 presently under 65kLux and seasonrelated decreasing.

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

Re: Lacrosse WS2500-19 brightness sensor

#20 Post by Ton_vN » 19 Oct 2023, 10:36

Winter 2023-2024 provides plenty of time to implement a firmware-update before the high range is again needed in spring/summer of 2024:
when is firmware-update released?

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

Re: Lacrosse WS2500-19 brightness sensor

#21 Post by Ton_vN » 31 Dec 2023, 08:37

Don't see it specifically mentioned in the description of mods,
but has this 'required upgrade' for WS2500/19 aka WS7000/19 been included in version 1.1 R50 for the RFLink-firmware?

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

Re: Lacrosse WS2500-19 brightness sensor

#22 Post by Ton_vN » 19 Jan 2024, 09:06

RFLink-firmware requires an upgrade (as requested since July 2022) to get satisfactory operation of light-sensor WS2500/19 aka WS7000/19 with correct MSB-handling.
No sign that such WS7000/19-update according to test-firmware v49.4 has been incorporated in any firmware upto/incl. v51.
Because neither any reaction from the Stuntteam, have to assume that no longer an upgrade-inclusion is being planned.
Consequence:
Correct RFLink-operation for WS2500/19 and WS7000/19 as well as clones of those devices is not possible for lightlevels >65kLux due to faulty firmware.

For my configuration no other practical solution left than continued use for RFLinkGateway of the test-firmware v49.4
plus pragmatically putting an attenuation cap over the Lightsensor of my WS7000/19-clone to reduce sensor-level within range of RFLink-handling
plus multiply the output by a general correction-factor.
Calibration? Forget it => the lightsensor just becomes a rough indicator for lightlevel.

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

Re: Lacrosse WS2500-19 brightness sensor

#23 Post by Stuntteam » 24 Jan 2024, 16:26

It has been fixed and tested.
It will be in the upcoming release (52).
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8

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

Re: Lacrosse WS2500-19 brightness sensor

#24 Post by Ton_vN » 28 Jan 2024, 14:23

Thanks!
For next summer finally getting rid, either of that upper limit clamping, or the use of an attenuation-cap ..............
.
Readout by Domoticz (behind) RFLinkGTW) for lightlevel of WS7000P19
Readout by Domoticz (behind) RFLinkGTW) for lightlevel of WS7000P19
chart_WS7000P19_2023 [640x480].jpeg (42.08 KiB) Viewed 1647 times
.
WS7000P19_capped
WS7000P19_capped
WS7000P19_capped [50%].jpg (24.41 KiB) Viewed 1547 times
Simplest attenuation-cap is from deodorantroller, internally smoothed to get uniform thickness of the 'wall'.
By earlier experience this pink version has an attenuation-factor of approx. 3

Post Reply

Who is online

Users browsing this forum: No registered users and 13 guests