Campbell Scientific CR300 data logger

[Craig Young]

Is there a driver for the CR300 data logger?  If not, I have a PC connected to the data logger, collecting the live data stream which I can reformat and send as either RS232 or UDP/IP packets to weewx in any format.  Would need a recommendation on which protocol to use.  But hopefully, there is already a driver for the CR300 or a 'generic' driver.

Craig

[p q]

I don't know the answer to the primary question.

As to recommended protocols, I'd choose MQTT.

On Sat, Apr 22, 2023 at 5:53 PM Craig Young <craig.y...@gmail.com> wrote:

Is there a driver for the CR300 data logger?  If not, I have a PC connected to the data logger, collecting the live data stream which I can reformat and send as either RS232 or UDP/IP packets to weewx in any format.  Would need a recommendation on which protocol to use.  But hopefully, there is already a driver for the CR300 or a 'generic' driver.

Craig

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com.

--

Peter Quinn
(415)794-2264

[DR]

Craig, I don't know of a driver for the Campbell dataloggers.

I wish there were one, I have a very dependable station (CR3000) that I'd like to interface.  Right now it is filling the native tables, and a Weather Display driver using pakbus is pulling those values from that table and handing them off to Weather Display, so I know 'something' could be made to work.

I am using a Texas Weather Instruments which, with the help of someone who knows Python a lot better than me, helped to get running.  It basically sends a send data command and then a data string gets sent from the TWI, which the driver then parses and loads into a packet and hands off to WeeWx.  I'm assuming that it can be adapted to other devices.

I am trying to learn Python well enough to write or modify a driver and the learning curve for this old FORTRAN and ALGOL guy is steeper than I thought it would be, but I am getting closer.  Things like synchronization with an incoming unrequested stream and how packets are formed and sent seem to by my next steps.

I wish I could say that within a few months I'd have a polished working driver, but with many other demands on my free time, progress is slow.

If  you've got a program on your PC that pulls in the live data stream you are perhaps in a much better place to write a routine to emulate that process and then look at how, for instance, the TWI driver forms a packet to hand off to WeeWx. 

I'm hoping you could use that little info to plan on how to get a working driver that you might share with the rest of us.  My encouragement to make it work is all I can give you otherwise, but sounds like you are pretty close.

The MQTT recommendation is something you might look at, too.   I know little about that.  I am grateful to those who have furnished so much already.  Dale

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAA1SM22-7QQ_GPRJHG1j%2Be5U99aKMzh3-VS0YKGU4Ob2KDSywg%40mail.gmail.com.

[Craig Young]

By any chance can weewx read from a data file?  I could write the incoming real time data to the file as a one line record and then weewx would read this, say once a second or so.

[vince]

Start with https://github.com/weewx/weewx/wiki/intake-strategies but short answer is sure.  If you can get the data in any format it is possible to get it into weewx via a variety of methods.   You might also poke around https://github.com/weewx/weewx/wiki#extensions-to-weewx for too many examples to get into in a reply.

Once/second is a bit quick however.  Does your data need to be that real-time ?

[Craig Young]

I update about every 15 seconds.  The one second was to shorten the time between when the data file is updated and when weewx reads it.  But I will look at the intake-strategies document and see what is available.

[DR]

I, too, need to follow Vince's advice as I'm looking for any leads.

One thing you asked about is getting info from a file, and I looked at a routine called FileParser (I think) that was associated with a search on github and weewx.

If I recall, it pulled in things from a file, parsed the record, assigned the values to the correct schema plan.  The only thing was it needed a paring, sort of like a dictionary entry rather than an ordered list, but I think that one could set a structure with incoming values at expected locations within the file rather than being so general as to search the whole string for the right key:value pair.  One is more versatile and robust at the expense of more preparation of the source file.    Just my two cents worth (you'll note I don't have a functioning driver yet, so what I say is tempered by depth of knowledge.)

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/99592c0e-762c-4b0f-83b7-cedf1465abecn%40googlegroups.com.

[DR]

Once a second seems more than enough.  Even the venerable Davis Loop is every two seconds.  I don't know how quickly things need to be read during a heavy rainstorm, but I would think that the hardware would be keeping track of tips, if using a tipper mechanism.

I only look at the Currrent values and the plots generated by the Seasons skin and updating every second would be a waste of CPU, I'd think.

Dale

On 4/22/2023 9:28 PM, Craig Young wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/99592c0e-762c-4b0f-83b7-cedf1465abecn%40googlegroups.com.

[vince]

You didn't say which os you're using, but one option would be to generate the same input that other drivers already use, and simply reuse an existing weewx driver designed for a different vendor.

For example - the WeatherFlow UDP driver listens for broadcasts that meet the published WeatherFlow UDP API (basically you want to simply broadcast JSON-formatted data).   If you could emit your data the same way and stick with the WF UDP API format, you could just use that existing driver to get your data into weewx with no weewx coding required.

I have a super-minimal simulator tool in python (link) that you could perhaps use as a starting point for one way to emit the expected UDP.  The WF API is (here) if you wanted to see what that vendor's station broadcasts.  If you can get your data out of your logger and broadcast UDP meeting their API, you probably could connect the dots.

Just a thought.  I'm sure you could follow similar paths to reuse other weewx drivers.

[Craig Young]

Exactly what I was looking for.  I can send UDP packets to simulate the WeatherFlow device and use the existing driver.  The WF API documentation is perfect .. I will duplicate that in my controller.  Thanks Vince.

Craig