Hi, Gary

A couple of things to keep in mind:

   1. Generally, I think you're better off with one instance for each
   device. Yes, people have written services that can poll additional devices,
   but this is a bit of a kludge. The one-instance/one-device pattern makes
   startup simpler, allows the device to participate in a "catch up" (if it
   has a suitable memory) and makes it easier to keep track of the origin of
   each bit of data.
   2. The difference between LOOP packets and archive records is that the
   former come at irregular intervals and possibly with irregular sets of
   data, while the latter comes at regular intervals and (usually) with all
   data types present. If you choose the latter, you should make sure you do
   the polling at precisely, say, 5 minute intervals.
   3. You definitely do not want to mix observations with different
   timestamps into a single loop packet.

I'm not sure I answered your questions. If not, give me another try!

-tk


On Sun, Jun 25, 2017 at 8:22 PM, gjr80 <gjroder...@gmail.com> wrote:

> I have had a Bloomsky Sky2 since October and have finally gotten around to
> resurrecting some lost work on putting together a driver. As per Matthew's
> suggestion
> <https://groups.google.com/d/msg/weewx-user/lQTs3mvwq7o/dVu5CF0gAQAJ> I
> have based it on the Netatmo driver and it appears to work well. I only
> have a Sky2 and not a Storm so have been unable to test it with any rain or
> wind related obs, though as Matthew says the Bloomsky API is trivial (if
> anyone has a Storm and would be prepared to let me test with an API key
> that would be great).
>
> So what. I originally bought the Sky2 due to its fish-eye lens camera that
> is solar powered and has wifi, the weather observation abilities of the
> Sky2 played no real part as I would much rather trust my VP2. That being
> said I would still like to be able to add the Bloomsky obs to weeWX. Given
> I will not be giving up the VP2, that means I really have 2 options; (1)
> run 2 instances of weeWX; one each running the vantage and Bloomsky drivers
> or (2) run a single weeWX instance with the vantage driver and pull in the
> Bloomsky data via a weeWX service. I don't really want to run 2 instances
> of weeWX so I am looking at the Bloomsky service approach. The Bloomsky
> docs state that Bloomsky device phone home to Bloomsky every 5-8 minutes
> and submit their data. You get Bloomsky data onto your PC via their app or
> by querying the Bloomsky API, you don't talk directly to the Bloomsky
> device. When implementing the Bloomsky driver, a separate thread polls the
> Bloomsky API every so often (lets say 60 seconds) and places the decoded
> response in a queue. When the driver receives data in the queue it then
> packages it into a loop packet and emits the packet. WeeWX takes care of
> the rest. In implementing a service, the Bloomsky service will be bound to
> either the NEW_LOOP_PACKET or NEW_ARCHIVE_RECORD events and the service
> will need to augment existing loop packets and/or archive records rather
> than create loop packets.
>
> How to hit the API and augment a packet/record is simple, already doing
> that in a driver but the issue I am pondering now is when to hit the API.
> For example, my VP2 has a 2-odd second loop period, Bloomsky has nothing
> documented about how often you can query their API but I think every 2
> seconds is a bit excessive, especially for such slow changing data. I could
> stick to polling every minute (user settable) as I do in the Bloomsky
> driver, but what if this is used with a station/driver whose loop period is
> somewhat more than 60 seconds (does such a beast exist?), Bloomsky data
> will back up in a queue, how do I then squeeze more than one Bloomsky obs
> into a single loop packet. All of the other services I have seen pull data
> from a register or some other local hardware device where blocking/delays
> are not an issue. In this case the 'query' is sent via the internet to
> Bloomsky and it could take some time or even fail after a number of
> retries/retry wait periods.
>
> Would appreciate any thoughts.
>
> Gary
>

Reply via email to