Yes, that section covers it fairly well. The two main things to watch are not delaying the main WeeWX engine loop and ensuring the data you add to the loop packet follows the unit system used in the loop packet. Delaying the main loop is often associated with accessing data via the internet or some other network. A common approach is to develop the data service without using its own thread, this makes debugging much easier. If delay is an issue you can move the service to its own thread later. Unit consistency is achieved by checking the usUnits field in the loop packet and then converting your service' data to the correct units. This is important for obs whose units that vary across unit systems (eg temperature) but not an issue if the same unit is used across all unit systems (eg wind direction). A robust, well written data service will not assume the loop packet always uses the same unit system.
Gary On Thursday, 27 April 2023 at 01:24:52 UTC+10 [email protected] wrote: > Thank you I expect you are referring to the Customization guide > "Customizing the WeeWX service engine; Adding a second data source"; I will > try doing it that way; Thanks again; > > On Tuesday, April 25, 2023 at 10:16:18 PM UTC-7 gjr80 wrote: > >> I'm not sure if you are providing a running commentary or seeking help. >> If the latter then I have no idea where to start. Personally, I think your >> architecture is way too complex; you appear to be running a highly modified >> driver that seeks to amalgamate data from two sources. I imagine you will >> strike all sorts of corner cases depending on what arrives when. I would >> also question the utility of reading indoor obs every seven seconds, seems >> way too frequent to me. All told I doubt you are going to find too many >> folks here to help. >> >> Why not run a standard sdr driver to feed WeeWX with loop packets from >> the Atlas with a simple, non-threaded data service bound to the new loop >> packet arrival to read the 'indoor data' (I assume this is pressure, >> temperature and humidity) and augment the loop packet. Far more modular and >> easier to test/develop (and get help), you will be running a standard sdr >> driver, and since you are already getting your hands dirty modifying the >> sdr driver, writing a small data service to handle the Arduino input should >> be a walk in the park. If the Arduino is serially connected to the RPi you >> should not have great latency in accessing data, so a suitably short >> timeout on the serial reads should provide you with you indoor data without >> blocking the main WeeWX thread. Once proved, the serial read could be moved >> to a thread if you really had the need. >> >> Gary >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/62f2dd56-7767-4630-a06d-2106e5610e49n%40googlegroups.com.
