Simulator - enhancement req - add new value generators

[Graham Eddy]

enhancement request to be able to add new value generators to weewx.drivers.Simulator from user.extensions (rather than edit a private copy)

easiest way i see is to just move self.observations to class attribute and let folk extend the list. this would be facilitated by an abstract class for Observation, Rain, Solar, BatteryStatus, BatteryVoltage, SignalStrength of form

class AbstractObservation(object):

  def value_at(self, time_ts):

  raise NotImplementedError

for developers to subclass their own value generators. mind you, the existing ones are pretty flexible - i used BatteryStatus as stimulus for lightning_strike_count.

otherwise, to avoid class attribute, could add method like add_observation_type(obs_type, value_generator)

[Tom Keffer]

Why not just subclass class Simulator? In the __init__ function of your new class, call the superclass's initializer, then add additional types to self.observations.

You would also have to provide your own loader() function, which would largely replicate the logic in the existing loader().

But, I take your point: class Simulator could be structured to make it easier to subclass and provide specialized simulators.

-tk

--
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/A9B73A87-8EC7-4B37-8458-5FDA979FC4CF%40gmail.com.

[Tom Keffer]

Try this version of the simulator. It should be a little easier to subclass.

[Graham Eddy]

close to working. but in my __init__, when i alter self.observations after calling super(..), it is after the ‘observations’ filter from weewx.conf has been applied. so, after carefully disabling some of my new value types by excluding them from ‘observations’ filter (Simulator.__init__ dutifully deletes unwanted value types if they are present at that time), my __init__ just adds them to self.observations afterwards. i don’t want to have to re-apply the ‘observations’ filter in my __init__!

and now it is 3am, i am off…

cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEA_iY4_noqo5v0mnV_mFnB5%2BPHbDK21h%2B8pTrLjK1dRoA%40mail.gmail.com.

[Graham Eddy]

i forgot to ask: start_ts is outside my __init__’s scope, so should i use self.the_time? e.g.

import weewx.drivers.simulator as simulator

...        

# VP2 optional observations

        self.observations['extraTemp1'] = simulator.Observation(

            magnitude=4.0, average=50.0, period=18.0, phase_lag=12.0,

            start=self.the_time)

[Tom Keffer]

That's why I added the method trim_observations(). It allows you to tailor this behavior. For example, you could override trim_observations() and have it add your new types before calling the subclass's version. Or, v-v (not sure exactly what you're trying to accomplish).

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/46397A33-77A4-4204-8B45-372B96E65A48%40gmail.com.

[Tom Keffer]

On Tue, Aug 11, 2020 at 10:03 AM Graham Eddy <graha...@gmail.com> wrote:

i forgot to ask: start_ts is outside my __init__’s scope, so should i use self.the_time? e.g.

import weewx.drivers.simulator as simulator

...        

# VP2 optional observations

        self.observations['extraTemp1'] = simulator.Observation(

            magnitude=4.0, average=50.0, period=18.0, phase_lag=12.0,

            start=self.the_time)

Hmmm, perhaps start_ts should be a property? 

-tk

[Graham Eddy]

a step ahead of me once again!

calling trim_observations() after my additions did the trick and my subclassed Simulator is now working