Thanks, Gary for the confirmation.
Of course I am accustomed to check the processes running with ps, and
occasionally kill one if needed. But at that time, I didn't even think
about it. Maybe, because many of the services run within a docker container.
In deed, I did not run wee_config --reconfigure, because I first run gw1000
as a service, besides interceptor (which is kind of stupid, as both data
came from the same source). I did then replace interceptor with gw1000
driver, after I had detected
[StdCalibrate]
[[Corrections]]
radiation = luminosity/126.7 if luminosity is not None else None
which finally resulted in exactly the same data as those from interceptor.
I did not put an eye on loop_on_init then, although I should have....
BTW, in the user guide it is said to set the option to "1", not to "True".
I guess, "True" will work as well.
We will see, if all works, when I need to reboot again. In a year, or so...
-Peter
gjr80 schrieb am Dienstag, 9. Februar 2021 um 05:40:14 UTC+1:
> Peter,
>
> Some comments below.
>
> Gary
>
> On Tuesday, 9 February 2021 at 06:40:28 UTC+10 Vetti52 wrote:
>
>> Thanks for the comments. I checked weewx.conf for all "loop" entries, no
>> loop_on_init exists. So, by default, is it set to false?
>>
> Correct, the default setting is False and loop_on_init is not explicitly
> included in a new weewx.conf, the user needs to add it.
>
>
>> Shouldn't it be generally enabled for gw1000 driver?
>>
> I guess that comes down to the user. As of v0.1.0b11 the user is prompted
> to set loop_on_init when using wee_config --reconfigure to re-configure
> WeeWX to use the GW1000 driver as a driver (refer to v0.1.0b11 release
> notes <https://github.com/gjr80/weewx-gw1000/releases/tag/v0.1.0b11>),
> though those having installed an earlier version of the GW1000 driver would
> not need to run wee_config again and hence would not be prompted to set
> loop_on_init. I could force loop_on_init to True in the GW1000 extension
> installer but as that would apply to those using the GW1000 driver as a
> driver as well as those using the GW1000 driver as an extension but have
> chosen not to as those using it as a service may not wish to have
> loop_on_init set True.
>
>
>> I wonder, why weewx could not be started after exiting. To me, this
>> indicates, that it was in fact still running in this status for more than
>> 30 minutes.
>>
> I couldn't say, the definitive check at the time would have been been to
> do:
>
> $ ps -aux | grep weewx
>
> to see what if any WeeWX processes remained running.
>
>
>> I could stop it, which took some seconds, and then start it again. At
>> that stage the network was up and running, so everything worked well. As I
>> reboot the Raspberry very rarely, next time I might have forgotten about
>> this problem with the gw1000 and the Raspberry Pi after reboot. As the
>> gw1000 itself is continuously running and sending the data without
>> interruption to ecowitt, thus showing valid data on the WsView dashboard, I
>> might not check, that weewx does not receive data then. I'm getting old....
>>
>> If loop_on_init would also solve this issue, and additionally the problem
>> of a temporarily missing network connection to gw1000, this would indeed
>> overcome my solution with weewx.service, which only works at startup.
>>
>
>> As the Raspberry Pi has to serve some other services (cups, home
>> assistant, Unifi), I am not very happy with the idea to inspect
>> weewx/gw1000 after repeated reboots. Especially, if I do not exactly know,
>> which protocols have to be logged and evaluated. I could even assume, that
>> at next time, the network might have started slightly faster, so this issue
>> will not always be observable by chance. So, there should be a well defined
>> environment for testing, which I currently don't have.
>> Meanwhile, before I forget about it, I will enable weewx.service modified
>> with the Stanza mentioned above.
>>
> I guess either approach will solve the problem you experienced, certainly
> manually checking on the state of WeeWX/GW1000 driver after boot/WeeWX
> startup is not a practical approach.
>
>
>>
>> -Peter
>>
>
--
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/fc9bd4d0-718c-4d5c-8efb-69c60a97dbadn%40googlegroups.com.
