Hello Tom, Matthew (or anybody who knows) :-)
How can I get the default measurement dictionnary in the driver ?
Currently, I have define in weewx.conf a stupid dictionnary:
[[label_map]]
barometer = barometer
pressure = pressure
altimeter = altimeter
inTemp = inTemp
outTemp = outTemp
inHumidity = inHumidity
....
With all weewx expected values (db schema)
left side should be the mqtt topic (ex : weewx/outTemp )
this label map allow custom topics ( ex weewx/OT ) is ok with:
[[label_map]]
OT = outTemp
But I think it could be also easy just to have no label map in driver
config in weewx.conf and use default dict matching the database schema.
I dont know how I can get this dict from driver. any suggestions ?
Le jeudi 23 mars 2017 10:21:56 UTC+1, Wysiwyg a écrit :
>
> Hi Matthew and thanks for details informations !
>
> I tried the loop_on_init, works perfectly !
>
> Mar 23 10:02:46 localhost weewx[786]: import of driver failed: [Errno 101]
> Le réseau n'est pas accessible (<class 'socket.error'>)
> Mar 23 10:02:46 localhost weewx[786]: engine: Unable to load driver:
> [Errno 101] Le réseau n'est pas accessible
> Mar 23 10:02:46 localhost weewx[786]: **** Waiting 60 seconds then
> retrying...
> Mar 23 10:04:04 localhost weewx[786]: engine: retrying...
> Mar 23 10:04:04 localhost weewx[786]: engine: Using configuration file
> /etc/weewx/weewx.conf
>
>
> after 1 minute, weewx started correctly.
>
>
>
>
>
>
> Le lundi 20 mars 2017 17:28:04 UTC+1, mwall a écrit :
>>
>> On Monday, March 20, 2017 at 11:12:55 AM UTC-4, Wysiwyg wrote:
>>>
>>> also during the weekend I noticed that at reboot, as weewx start before
>>> my ethernet connexion is fully setup, it seems I get a crash (the driver is
>>> not able to connect).
>>>
>>> Is it possible to use this weewx.WeeWxIOError during the __init__ of
>>> the driver ?
>>>
>>
>> this situation is handled by the loop_on_init=True option in the weewx
>> configuration file.
>>
>> weewx is designed to fail hard on startup when system resources are not
>> available. for example, if the driver expects a usb device, but that usb
>> device is not plugged in, then the driver fails and weewx exits.
>> similarly, if a driver needs the network, but there is no nic or the
>> network subsystem is not up and running, then the driver fails and weewx
>> exits.
>>
>> once weewx is running, these kinds of failures are handled by the weewx
>> engine - the engine detects the driver failure, waits 60 seconds, then
>> starts over.
>>
>> the intent is that the user should be made aware of the problem during
>> startup, but once weewx is running, the engine should keep things running.
>>
>> lets call this the 'interactive' use case - a person is interactively
>> getting weewx to start up.
>>
>> however, there is another use case that has opposite goal from this - it
>> wants weewx to start running whether or not the things it needs are
>> attached/available. lets call this the 'set and forget' use case - you
>> configure a system that may or may not have all of the resources available
>> for weewx, and you want weewx to start working as soon as those resources
>> are available. for example, you might start up weewx when no usb devices
>> are plugged in, but you want weewx to automatically detect the devices and
>> start working as soon as they are plugged in. or you might have a
>> raspberry pi that takes a long time for networking to come up, but you want
>> weewx to start up anyway, then start working as soon as the network is
>> available.
>>
>> one way to do this would be to use udev rules/scripts to start/stop
>> weewx. another way is to use systemd (or init.d) dependencies.
>>
>> but the loop_on_init=True approach is much easier, and works for many use
>> cases.
>>
>> m
>>
>
