Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

On Sun, Nov 27, 2016 at 10:40 AM, Andrew Milner  wrote:

> .. or you could just say weewx does not support feather . and
> leave feather users to do their own thing  if doing software archive
> record generation from loop packets does not solve the problem.
>

​I could. But, that bucks the whole reason I wrote weewx in the first
place. I was a hardcore wview user, but also interested in experimenting
with new devices and algorithms. I found wview to be very brittle and very
difficult to ​modify. Everything required a change to the code base. So, I
wrote weewx.

Supporting the Dekay library is a fine example of the weewx approach. If
this suggestion works, it accommodates an inexpensive and incomplete
emulator of the Vantage series, while leveraging, and not modifying, the
existing code base.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Andrew Milner]

.. or you could just say weewx does not support feather . and leave 
feather users to do their own thing  if doing software archive record 
generation from loop packets does not solve the problem.



On Sunday, 27 November 2016 20:35:22 UTC+2, Tom Keffer wrote:

> I'm getting lost in where we are.
>
> Let me try another suggestion. If you do not or cannot implement GETTIME 
> on the feather, how about writing a new driver that inherits from the old 
> vantage driver, but overrides getTime() and setTime()?
>
> It would look something like this (NOT TESTED):
>
> *File bin/user/dekay.py*
>
> import weewx.drivers.vantage
>
> DRIVER_NAME = 'Dekay'
> DRIVER_VERSION = '0.0.1'
>
> def loader(config_dict, engine):
> return DekayService(engine, config_dict)
>
> configurator_loader = weewx.drivers.vantage.configuration_loader
> confeditor_loader = weewx.drivers.vantage.confeditor_loader
>
> class DekayService(weewx.drivers.vantage.VantageService):
>
> def getTime(self):
> raise NotImplementedError("Method 'getTime' not implemented in 
> Dekay driver")
>
> def setTime(self, ts):
> raise NotImplementedError("Method 'setTime' not implemented in 
> Dekay driver")
>
>
>
> To use, go into weewx.conf and change
>
> driver = weewx.drivers.vantage
>
> to
>
> driver = user.dekay
>
> I've probably forgotten a bunch of things, but this should get you started.
>
> -tk
>
>
>
>
> On Sun, Nov 27, 2016 at 10:19 AM, gustl319  > wrote:
>
>> Am Sonntag, 27. November 2016 14:05:56 UTC+1 schrieb Tom Keffer:
>>>
>>> On Sun, Nov 27, 2016 at 3:53 AM, gustl319  wrote:
>>>
 I've done some code searching. Please tell me if I'm right:

- on startup do_sync() is called
- in do_sync() is a call to getTime()
- getTime() returns the GETTIME answer
- if the difference to system time is greater than max_drift (5sec) 
then a setTime() -> SETTIME sequence is started

 ​This is exactly right.
>>>
>>>
>> Unfortunately real life is different :-( 
>>
>> When I remove the GETTIME command everyting is fine. When GETTIME returns 
>> a yet unset time from the past I get hundreds and thousands of Requesting 
>> 200 LOOP packets
>>
>> I edited vantage.py to generate syslog entrys when there is a getTime() 
>> or a setTime(). 
>> Nov 27 18:41:19 raspberrypi weewx[6839]: engine: Starting main packet 
>> loop.
>> Nov 27 18:41:19 raspberrypi weewx[6839]: vantage: getTime(self)
>>
>> I think this getTime is not called from do_sync, but from 
>> StdArchiv.pre_loop via engine._get_console_time(). The time calculates 
>> end_archive_period_ts and end_archive_delay_ts. My guess is that an 
>> anchient timestamp triggers these loop requests, because of these 
>> period/delay values. 
>>
>> So how does weewx recognize a batterie change in a vantage console and 
>> trigger a SETTIME?
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

I'm getting lost in where we are.

Let me try another suggestion. If you do not or cannot implement GETTIME on
the feather, how about writing a new driver that inherits from the old
vantage driver, but overrides getTime() and setTime()?

It would look something like this (NOT TESTED):

*File bin/user/dekay.py*

import weewx.drivers.vantage

DRIVER_NAME = 'Dekay'
DRIVER_VERSION = '0.0.1'

def loader(config_dict, engine):
return DekayService(engine, config_dict)

configurator_loader = weewx.drivers.vantage.configuration_loader
confeditor_loader = weewx.drivers.vantage.confeditor_loader

class DekayService(weewx.drivers.vantage.VantageService):

def getTime(self):
raise NotImplementedError("Method 'getTime' not implemented in
Dekay driver")

def setTime(self, ts):
raise NotImplementedError("Method 'setTime' not implemented in
Dekay driver")



To use, go into weewx.conf and change

driver = weewx.drivers.vantage

to

driver = user.dekay

I've probably forgotten a bunch of things, but this should get you started.

-tk




On Sun, Nov 27, 2016 at 10:19 AM, gustl319  wrote:

> Am Sonntag, 27. November 2016 14:05:56 UTC+1 schrieb Tom Keffer:
>>
>> On Sun, Nov 27, 2016 at 3:53 AM, gustl319  wrote:
>>
>>> I've done some code searching. Please tell me if I'm right:
>>>
>>>- on startup do_sync() is called
>>>- in do_sync() is a call to getTime()
>>>- getTime() returns the GETTIME answer
>>>- if the difference to system time is greater than max_drift (5sec)
>>>then a setTime() -> SETTIME sequence is started
>>>
>>> ​This is exactly right.
>>
>>
> Unfortunately real life is different :-(
>
> When I remove the GETTIME command everyting is fine. When GETTIME returns
> a yet unset time from the past I get hundreds and thousands of Requesting
> 200 LOOP packets
>
> I edited vantage.py to generate syslog entrys when there is a getTime()
> or a setTime().
> Nov 27 18:41:19 raspberrypi weewx[6839]: engine: Starting main packet loop.
> Nov 27 18:41:19 raspberrypi weewx[6839]: vantage: getTime(self)
>
> I think this getTime is not called from do_sync, but from
> StdArchiv.pre_loop via engine._get_console_time(). The time calculates
> end_archive_period_ts and end_archive_delay_ts. My guess is that an
> anchient timestamp triggers these loop requests, because of these
> period/delay values.
>
> So how does weewx recognize a batterie change in a vantage console and
> trigger a SETTIME?
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

I just found set_time(). It has somthing todo with option --set-time. Is 
this an option I can trigger via weewx.conf?

Thanks, Gustl

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Am Sonntag, 27. November 2016 14:05:56 UTC+1 schrieb Tom Keffer:
>
> On Sun, Nov 27, 2016 at 3:53 AM, gustl319  > wrote:
>
>> I've done some code searching. Please tell me if I'm right:
>>
>>- on startup do_sync() is called
>>- in do_sync() is a call to getTime()
>>- getTime() returns the GETTIME answer
>>- if the difference to system time is greater than max_drift (5sec) 
>>then a setTime() -> SETTIME sequence is started
>>
>> ​This is exactly right.
>
>
Unfortunately real life is different :-( 

When I remove the GETTIME command everyting is fine. When GETTIME returns a 
yet unset time from the past I get hundreds and thousands of Requesting 200 
LOOP packets

I edited vantage.py to generate syslog entrys when there is a getTime() or 
a setTime(). 
Nov 27 18:41:19 raspberrypi weewx[6839]: engine: Starting main packet loop.
Nov 27 18:41:19 raspberrypi weewx[6839]: vantage: getTime(self)

I think this getTime is not called from do_sync, but from StdArchiv.pre_loop 
via engine._get_console_time(). The time calculates end_archive_period_ts 
and end_archive_delay_ts. My guess is that an anchient timestamp triggers 
these loop requests, because of these period/delay values. 

So how does weewx recognize a batterie change in a vantage console and 
trigger a SETTIME?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

On Sun, Nov 27, 2016 at 3:53 AM, gustl319  wrote:

> I've done some code searching. Please tell me if I'm right:
>
>- on startup do_sync() is called
>- in do_sync() is a call to getTime()
>- getTime() returns the GETTIME answer
>- if the difference to system time is greater than max_drift (5sec)
>then a setTime() -> SETTIME sequence is started
>
> ​This is exactly right.



> So a datetime library for ardunio/feather which is set by SETTIME should
> do the trick.
>
>
​Yes, so long as getTime() always returns the correct time.
​


> Please tell me: Is do_sync() after every conection loss between weewx and
> the console?
>
>
​No. Only when weewx starts up, and thereafter, every 4 hours. ​


​-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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

I've done some code searching. Please tell me if I'm right:

   - on startup do_sync() is called
   - in do_sync() is a call to getTime()
   - getTime() returns the GETTIME answer
   - if the difference to system time is greater than max_drift (5sec) then 
   a setTime() -> SETTIME sequence is started

So a datetime library for ardunio/feather which is set by SETTIME should do 
the trick. 

Please tell me: Is do_sync() after every conection loss between weewx and 
the console?

Thanks, Gustl

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Am Sonntag, 27. November 2016 00:07:26 UTC+1 schrieb Tom Keffer:
>
> A dead battery shuts down the Vantage completely but, once replaced, weewx 
> will immediately set it to the correct time.
>

I asume this is done by GETTIME / SETTIME combination. During my try I 
never saw a SETTIME command. Is there a GETTIME answer (e.g. January 1st 
1970) that triggers a SETTIME?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Andrew Milner]

I must be missing something here isn't the answer to just run weewx on 
the rpi with the attached station acting like a vantage without a logger, 
and set weewx to software record generation - or does that combination also 
require a clock in the 'station'?  Not sure I really see what the feather 
is doing between the vantage and the Rpi.  Guess I just completely missing 
the point!!


On Sunday, 27 November 2016 01:07:26 UTC+2, Tom Keffer wrote:

> On Sat, Nov 26, 2016 at 1:36 PM, gustl319  > wrote:
>
>>
>> At the moment I don't understand why weewx want to know the time from 
>> Vantage via GETTIME. The only thing I can think of is data logging. I don't 
>> have EEPROM or Flash, so I can't do any logging. This could happen with a 
>> Vantage too (empty battery).
>>
>>
> You may not need them, but others do! The function getTime(), and its 
> partner setTime(), perform an extremely important role for Vantage consoles 
> with a logger, because they make sure the timestamps on the logger are kept 
> in sync with the weewx process. It's true that because you don't have a 
> logger you don't need them, but I'm not about to get rid of them just to 
> support the Dekay board! :-)
>
> A dead battery shuts down the Vantage completely but, once replaced, weewx 
> will immediately set it to the correct time.
>  
>
>> What would weewx do if a Vantage is out-of-date or in a different time 
>> zone.
>>
>
> ​Weewx would set the correct time the next time service StdTimeSynch is 
> run, which is on program startup, and, thereafter, every 4 hours.
>
> -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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

On Sat, Nov 26, 2016 at 1:36 PM, gustl319  wrote:

>
> At the moment I don't understand why weewx want to know the time from
> Vantage via GETTIME. The only thing I can think of is data logging. I don't
> have EEPROM or Flash, so I can't do any logging. This could happen with a
> Vantage too (empty battery).
>
>
You may not need them, but others do! The function getTime(), and its
partner setTime(), perform an extremely important role for Vantage consoles
with a logger, because they make sure the timestamps on the logger are kept
in sync with the weewx process. It's true that because you don't have a
logger you don't need them, but I'm not about to get rid of them just to
support the Dekay board! :-)

A dead battery shuts down the Vantage completely but, once replaced, weewx
will immediately set it to the correct time.


> What would weewx do if a Vantage is out-of-date or in a different time
> zone.
>

​Weewx would set the correct time the next time service StdTimeSynch is
run, which is on program startup, and, thereafter, every 4 hours.

-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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

A Dekay board without RTC ignores a GETTIME command a Vantage console does 
not.

Am Samstag, 26. November 2016 21:00:50 UTC+1 schrieb Tom Keffer:
>
> It's always a much better solution to improve the emulation, rather than 
> workaround any shortcomings.
>

Aggreed :-)
But to improove the emulation (Dekay Lib) one had to understand how things 
work with the real thing (Vantage).

At the moment I don't understand why weewx want to know the time from 
Vantage via GETTIME. The only thing I can think of is data logging. I don't 
have EEPROM or Flash, so I can't do any logging. This could happen with a 
Vantage too (empty battery).

What would weewx do if a Vantage is out-of-date or in a different time zone.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

>
>
> Why does it need a clock time? For datalogging while RPi is down?
>
> While, in theory, I don't have a problem adding support for the Dekay
library to the vantage driver, the solutions we have come up with so far
are very ad hoc, and can fail in other ways. For example, if the driver
detects a very out-of-date clock, how does it know it's talking to a Dekay
board with no RTC, versus a Vantage console that happens to be out-of-date?

It's always a much better solution to improve the emulation, rather than
workaround any shortcomings.

-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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

This library should do the trick:
http://playground.arduino.cc/Code/DateTime
But it needs to be set after a power down

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Am Samstag, 26. November 2016 19:31:01 UTC+1 schrieb Tom Keffer:
>
> Just thinking out loud, it is not necessary for the feather to have an 
> RTC. All that is necessary is that it can keep track of time once it is 
> set. This is similar to how an RPi works without an RTC. 
>
> Do you know if the feather can keep a running clock time?
>
> Arduino and Co are pretty new to me. But with the right library why not.

Why does it need a clock time? For datalogging while RPi is down? 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

Sorry. I should have looked up the call instead of guessing. The correct
call would be

datetime.datetime.now()



>  When there is no GETTIME answer it ends in syslog.syslog(...) correct?
> Then it should return a datetime contruct for the "now" date and time.
> Wouldn't that be a solution that covers Davis and 3rd party connectors?
>

​As I understand it, the problem is not that there is no answer to GETTIME,
but that the Dekay library responds with the wrong time.

I suppose one could detect this by setting a limit to how far off the time
can be. If GETTIME returns a really out-of-date answer, then time.time() is
substituted.

-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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Am Freitag, 25. November 2016 21:14:12 UTC+1 schrieb Tom Keffer:
>
> Yes, alternatively getConsoleTime could be implemented as:
>
> ​def getConsoleTime(self):
> ​return datetime.datetime()
>
>
Does not work! 
datetime.datetime() needs valid parameters yr, mon, day, hr... 
I tried datetime.now() but got these errors:

Nov 26 15:10:50 raspberrypi weewx[3367]:   return datetime.now
Nov 26 15:10:50 raspberrypi weewx[3367]:   AttributeError: 'module' 
object has no attribute 'now'
Nov 26 15:10:50 raspberrypi weewx[3367]:   Exiting.

Here's some code:

def getConsoleTime(self):
"""Return the raw time on the console, uncorrected for DST or 
timezone."""

# Try up to max_tries times:
for unused_count in xrange(self.max_tries):
try:
# Wake up the console...
self.port.wakeup_console(max_tries=self.max_tries)
# ... request the time...
self.port.send_data('GETTIME\n')
# ... get the binary data. No prompt, only one try:
_buffer = self.port.get_data_with_crc16(8, max_tries=1)
(sec, minute, hr, day, mon, yr, unused_crc) = 
struct.unpack("

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

On Dekay Lib:
A GETTIME command is always responded with the same static time (Januar 1st 
2016 1:00:00). 
On weewx:
getConsoleTime() gets an answer on GETTIME and causes no errors.
getTime() corrects the time to time.time() + 0.5 

At the moment this works for me. But getConsoleTime() is also used for 
setting console_time. I think it would be good to move 'time.time() + 0.5' 
from getTime() to getConsoleTime(). But it has a different format and 
should only be used when the syslog entry is triggered.

BTW is the offset '+0.5' neccessary?

Thanks again

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

I'm not following.

I don't know how the Dekay libraries work, but I assume they emulate the
Davis Vantage API. So, it must respond to a GETTIME command with something,
but if the feather has no clock, what is it returning?

>From your later note, it sounds like everything is working. What did you
change?

-tk



On Fri, Nov 25, 2016 at 10:29 AM, gustl319  wrote:

> It had no effect because GETTIME was still missing. Now with a fake
> GETTIME and your code I get this.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Just checked index.html
Temp and Hum are the same as in the console.
So far it looks good.

Thanks a lot

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

It had no effect because GETTIME was still missing. Now with a fake GETTIME 
and your code I get this.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


syslog.test
Description: Binary data

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

>
> I just tried that. It just seems to have no efect. I'm not familiar with
>> phyton. Must I run a compile script?
>>
>
>>
​No. Just restart weewx. Python is an interpreted language.

And, please don't just say "has no effect." Some details please. In
particular* post the log!*

-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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Am Freitag, 25. November 2016 18:58:30 UTC+1 schrieb Tom Keffer:
>
> I don't think it is as simple as removing the GETTIME command. 
>
Just recognized that :-(
 

> Weewx detects the lack of an onboard clock by making a call to the 
> *driver* function getTime(). If has not been implemented, then it falls 
> back to the system clock.
>
> Unfortunately, even if you remove the GETTIME command, the function 
> getTime() will still be implemented in the driver. It's just that it's 
> getting the wrong answer.
>
> Let's try an experiment. Go into the driver file vantage.py and change 
> these lines
>
> def getTime(self):
> """Get the current time from the console, returning it as 
> timestamp"""
>
> time_dt = self.getConsoleTime()
> return time.mktime(time_dt.timetuple())
>
> to this
>
> def getTime(self):
> """Get the current time from the console, returning it as 
> timestamp"""
>
> return int(time.time() + 0.5)
>
> See if that solves your problem. If it does, then we can find a more 
> permanent solution.
>
>
I just tried that. It just seems to have no efect. I'm not familiar with 
phyton. Must I run a compile script?  

> -tk
>
>
> On Fri, Nov 25, 2016 at 8:29 AM, gustl319  > wrote:
>
>> I think I can remove the GETTIME command. archive_delay is still at 15 
>> seconds. I come back later.
>>
>>
>>
>> Am Freitag, 25. November 2016 17:08:48 UTC+1 schrieb Tom Keffer:
>>>
>>> The timestamp for the loop packets come from weewx. So, if the clock on 
>>> the RPi is correct, then the loop packet timestamps should be correct. If 
>>> you run weewx directly from the command line 
>>> , you can 
>>> monitor these timestamps and see if they are correct. 
>>>
>>> However, the main loop in the weewx engine uses the time on the console 
>>> to decide when to stop asking for LOOP packets and, instead, calculate and 
>>> save an archive record. If the console does not supply a time, then weewx 
>>> uses the system clock on the RPi.
>>>
>>> It's possible that the DeKay library is providing a time, but because of 
>>> the lack of a RTC on the feather, it's supplying an incorrect time. If it 
>>> cannot supply a correct time, then it shouldn't provide one at all. That 
>>> is, it should not implement the Vantage GETTIME command. 
>>>
>>> I don't know how the DeKay library is structured, but this may not be 
>>> possible. In that case, we'd have to figure out some other way of deciding 
>>> when the clock on a Vantage is unavailable. 
>>>
>>> I think this would explain the many requests for "200 LOOP packets," but 
>>> it's hard for me to follow the log because of your annotations. They 
>>> chopped it up into disconnected pieces, with some missing between. Can you 
>>> just post a continuous log, without annotations?
>>>
>>> Finally, the archiving service should not attempt to save an archive 
>>> record until after a specified "archive_delay," (generally 15 seconds), yet 
>>> your log shows it attempting a save with only a one second delay. Did you 
>>> modify the default archive_delay?
>>>
>>> -tk
>>>
>>> On Fri, Nov 25, 2016 at 7:44 AM, gustl319  wrote:
>>>
 Thanks for the fast response.

 Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:
>
> Please read the User's Guide, section 3rd party Vantage connectors 
>  and 
> see if that answers your question. 
>

 Unfortunately your link didn't answer my question, but changed the 
 problem :-(
 In the 1st part of log everthing seem fine.

 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx 
> version 3.6.1
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3 
> (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform 
> Linux-3.18.7+-armv6l-with-debian-7.8
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is 
> /var/run/weewx.pid
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration 
> file /etc/weewx/weewx.conf
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type 
> Vantage (weewx.drivers.vantage)
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is 
> 3.0.9
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial 
> port /dev/ttyACM0; baud 19200; timeout 4.00
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of 
> console successful
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware 
> type is 17
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
> weewx.engine.StdConvert
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: 

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

I don't think it is as simple as removing the GETTIME command.

Weewx detects the lack of an onboard clock by making a call to the
*driver* function
getTime(). If has not been implemented, then it falls back to the system
clock.

Unfortunately, even if you remove the GETTIME command, the function
getTime() will still be implemented in the driver. It's just that it's
getting the wrong answer.

Let's try an experiment. Go into the driver file vantage.py and change
these lines

def getTime(self):
"""Get the current time from the console, returning it as
timestamp"""

time_dt = self.getConsoleTime()
return time.mktime(time_dt.timetuple())

to this

def getTime(self):
"""Get the current time from the console, returning it as
timestamp"""

return int(time.time() + 0.5)

See if that solves your problem. If it does, then we can find a more
permanent solution.

-tk


On Fri, Nov 25, 2016 at 8:29 AM, gustl319  wrote:

> I think I can remove the GETTIME command. archive_delay is still at 15
> seconds. I come back later.
>
>
>
> Am Freitag, 25. November 2016 17:08:48 UTC+1 schrieb Tom Keffer:
>>
>> The timestamp for the loop packets come from weewx. So, if the clock on
>> the RPi is correct, then the loop packet timestamps should be correct. If
>> you run weewx directly from the command line
>> , you can monitor
>> these timestamps and see if they are correct.
>>
>> However, the main loop in the weewx engine uses the time on the console
>> to decide when to stop asking for LOOP packets and, instead, calculate and
>> save an archive record. If the console does not supply a time, then weewx
>> uses the system clock on the RPi.
>>
>> It's possible that the DeKay library is providing a time, but because of
>> the lack of a RTC on the feather, it's supplying an incorrect time. If it
>> cannot supply a correct time, then it shouldn't provide one at all. That
>> is, it should not implement the Vantage GETTIME command.
>>
>> I don't know how the DeKay library is structured, but this may not be
>> possible. In that case, we'd have to figure out some other way of deciding
>> when the clock on a Vantage is unavailable.
>>
>> I think this would explain the many requests for "200 LOOP packets," but
>> it's hard for me to follow the log because of your annotations. They
>> chopped it up into disconnected pieces, with some missing between. Can you
>> just post a continuous log, without annotations?
>>
>> Finally, the archiving service should not attempt to save an archive
>> record until after a specified "archive_delay," (generally 15 seconds), yet
>> your log shows it attempting a save with only a one second delay. Did you
>> modify the default archive_delay?
>>
>> -tk
>>
>> On Fri, Nov 25, 2016 at 7:44 AM, gustl319  wrote:
>>
>>> Thanks for the fast response.
>>>
>>> Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:

 Please read the User's Guide, section 3rd party Vantage connectors
  and
 see if that answers your question.

>>>
>>> Unfortunately your link didn't answer my question, but changed the
>>> problem :-(
>>> In the 1st part of log everthing seem fine.
>>>
>>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx
 version 3.6.1
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3
 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform
 Linux-3.18.7+-armv6l-with-debian-7.8
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is
 /var/run/weewx.pid
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration
 file /etc/weewx/weewx.conf
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type
 Vantage (weewx.drivers.vantage)
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is
 3.0.9
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial port
 /dev/ttyACM0; baud 19200; timeout 4.00
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of
 console successful
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware type
 is 17
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service
 weewx.engine.StdConvert
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: StdConvert target unit
 is 0x1
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Finished loading
 service weewx.engine.StdConvert
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service
 weewx.engine.StdCalibrate
 Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading
 service weewx.engine.StdCalibrate
 Nov 25 15:54:11 raspberrypi weewx[8936]: 

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

I tried to atach the log file. hope you can read it

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


syslog.constRTC
Description: Binary data

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Andrew Milner]

You might not have changed the archive delay - but what is the archive 
interval set to??


On Friday, 25 November 2016 18:29:55 UTC+2, gustl319 wrote:

> I think I can remove the GETTIME command. archive_delay is still at 15 
> seconds. I come back later.
>
>
>
> Am Freitag, 25. November 2016 17:08:48 UTC+1 schrieb Tom Keffer:
>>
>> The timestamp for the loop packets come from weewx. So, if the clock on 
>> the RPi is correct, then the loop packet timestamps should be correct. If 
>> you run weewx directly from the command line 
>> , you can monitor 
>> these timestamps and see if they are correct. 
>>
>> However, the main loop in the weewx engine uses the time on the console 
>> to decide when to stop asking for LOOP packets and, instead, calculate and 
>> save an archive record. If the console does not supply a time, then weewx 
>> uses the system clock on the RPi.
>>
>> It's possible that the DeKay library is providing a time, but because of 
>> the lack of a RTC on the feather, it's supplying an incorrect time. If it 
>> cannot supply a correct time, then it shouldn't provide one at all. That 
>> is, it should not implement the Vantage GETTIME command. 
>>
>> I don't know how the DeKay library is structured, but this may not be 
>> possible. In that case, we'd have to figure out some other way of deciding 
>> when the clock on a Vantage is unavailable. 
>>
>> I think this would explain the many requests for "200 LOOP packets," but 
>> it's hard for me to follow the log because of your annotations. They 
>> chopped it up into disconnected pieces, with some missing between. Can you 
>> just post a continuous log, without annotations?
>>
>> Finally, the archiving service should not attempt to save an archive 
>> record until after a specified "archive_delay," (generally 15 seconds), yet 
>> your log shows it attempting a save with only a one second delay. Did you 
>> modify the default archive_delay?
>>
>> -tk
>>
>> On Fri, Nov 25, 2016 at 7:44 AM, gustl319  wrote:
>>
>>> Thanks for the fast response.
>>>
>>> Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:

 Please read the User's Guide, section 3rd party Vantage connectors 
  and 
 see if that answers your question. 

>>>
>>> Unfortunately your link didn't answer my question, but changed the 
>>> problem :-(
>>> In the 1st part of log everthing seem fine.
>>>
>>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx 
 version 3.6.1
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3 
 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform 
 Linux-3.18.7+-armv6l-with-debian-7.8
 Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is 
 /var/run/weewx.pid
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration 
 file /etc/weewx/weewx.conf
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type 
 Vantage (weewx.drivers.vantage)
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is 
 3.0.9
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial port 
 /dev/ttyACM0; baud 19200; timeout 4.00
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of 
 console successful
 Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware type 
 is 17
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
 weewx.engine.StdConvert
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: StdConvert target unit 
 is 0x1
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Finished loading 
 service weewx.engine.StdConvert
 Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
 weewx.engine.StdCalibrate
 Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading 
 service weewx.engine.StdCalibrate
 Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
 weewx.engine.StdQC
 Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading 
 service weewx.engine.StdQC
 Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
 weewx.wxservices.StdWXCalculate
 Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following 
 values will be calculated: barometer=prefer_hardware, windchill=prefer_hard
 ware, dewpoint=prefer_hardware, appTemp=prefer_hardware, 
 rainRate=prefer_hardware, windrun=prefer_hardware, 
 heatindex=prefer_hardware, maxSolar
 Rad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, 
 inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardwa
 re, cloudbase=prefer_hardware
 Nov 25 15:54:11 raspberrypi 

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

I think I can remove the GETTIME command. archive_delay is still at 15 
seconds. I come back later.



Am Freitag, 25. November 2016 17:08:48 UTC+1 schrieb Tom Keffer:
>
> The timestamp for the loop packets come from weewx. So, if the clock on 
> the RPi is correct, then the loop packet timestamps should be correct. If 
> you run weewx directly from the command line 
> , you can monitor 
> these timestamps and see if they are correct. 
>
> However, the main loop in the weewx engine uses the time on the console to 
> decide when to stop asking for LOOP packets and, instead, calculate and 
> save an archive record. If the console does not supply a time, then weewx 
> uses the system clock on the RPi.
>
> It's possible that the DeKay library is providing a time, but because of 
> the lack of a RTC on the feather, it's supplying an incorrect time. If it 
> cannot supply a correct time, then it shouldn't provide one at all. That 
> is, it should not implement the Vantage GETTIME command. 
>
> I don't know how the DeKay library is structured, but this may not be 
> possible. In that case, we'd have to figure out some other way of deciding 
> when the clock on a Vantage is unavailable. 
>
> I think this would explain the many requests for "200 LOOP packets," but 
> it's hard for me to follow the log because of your annotations. They 
> chopped it up into disconnected pieces, with some missing between. Can you 
> just post a continuous log, without annotations?
>
> Finally, the archiving service should not attempt to save an archive 
> record until after a specified "archive_delay," (generally 15 seconds), yet 
> your log shows it attempting a save with only a one second delay. Did you 
> modify the default archive_delay?
>
> -tk
>
> On Fri, Nov 25, 2016 at 7:44 AM, gustl319  > wrote:
>
>> Thanks for the fast response.
>>
>> Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:
>>>
>>> Please read the User's Guide, section 3rd party Vantage connectors 
>>>  and 
>>> see if that answers your question. 
>>>
>>
>> Unfortunately your link didn't answer my question, but changed the 
>> problem :-(
>> In the 1st part of log everthing seem fine.
>>
>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx 
>>> version 3.6.1
>>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3 
>>> (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
>>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform 
>>> Linux-3.18.7+-armv6l-with-debian-7.8
>>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is 
>>> /var/run/weewx.pid
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration 
>>> file /etc/weewx/weewx.conf
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type 
>>> Vantage (weewx.drivers.vantage)
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is 3.0.9
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial port 
>>> /dev/ttyACM0; baud 19200; timeout 4.00
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of 
>>> console successful
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware type 
>>> is 17
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
>>> weewx.engine.StdConvert
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: StdConvert target unit 
>>> is 0x1
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Finished loading 
>>> service weewx.engine.StdConvert
>>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
>>> weewx.engine.StdCalibrate
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading 
>>> service weewx.engine.StdCalibrate
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
>>> weewx.engine.StdQC
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading 
>>> service weewx.engine.StdQC
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
>>> weewx.wxservices.StdWXCalculate
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following 
>>> values will be calculated: barometer=prefer_hardware, windchill=prefer_hard
>>> ware, dewpoint=prefer_hardware, appTemp=prefer_hardware, 
>>> rainRate=prefer_hardware, windrun=prefer_hardware, 
>>> heatindex=prefer_hardware, maxSolar
>>> Rad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, 
>>> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardwa
>>> re, cloudbase=prefer_hardware
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following 
>>> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
>>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading 
>>> service weewx.wxservices.StdWXCalculate
>>> Nov 25 15:54:11 

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

The timestamp for the loop packets come from weewx. So, if the clock on the
RPi is correct, then the loop packet timestamps should be correct. If you run
weewx directly from the command line
, you can monitor
these timestamps and see if they are correct.

However, the main loop in the weewx engine uses the time on the console to
decide when to stop asking for LOOP packets and, instead, calculate and
save an archive record. If the console does not supply a time, then weewx
uses the system clock on the RPi.

It's possible that the DeKay library is providing a time, but because of
the lack of a RTC on the feather, it's supplying an incorrect time. If it
cannot supply a correct time, then it shouldn't provide one at all. That
is, it should not implement the Vantage GETTIME command.

I don't know how the DeKay library is structured, but this may not be
possible. In that case, we'd have to figure out some other way of deciding
when the clock on a Vantage is unavailable.

I think this would explain the many requests for "200 LOOP packets," but
it's hard for me to follow the log because of your annotations. They
chopped it up into disconnected pieces, with some missing between. Can you
just post a continuous log, without annotations?

Finally, the archiving service should not attempt to save an archive record
until after a specified "archive_delay," (generally 15 seconds), yet your
log shows it attempting a save with only a one second delay. Did you modify
the default archive_delay?

-tk

On Fri, Nov 25, 2016 at 7:44 AM, gustl319  wrote:

> Thanks for the fast response.
>
> Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:
>>
>> Please read the User's Guide, section 3rd party Vantage connectors
>>  and
>> see if that answers your question.
>>
>
> Unfortunately your link didn't answer my question, but changed the problem
> :-(
> In the 1st part of log everthing seem fine.
>
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx
>> version 3.6.1
>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3
>> (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform
>> Linux-3.18.7+-armv6l-with-debian-7.8
>> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is
>> /var/run/weewx.pid
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration file
>> /etc/weewx/weewx.conf
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type
>> Vantage (weewx.drivers.vantage)
>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is 3.0.9
>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial port
>> /dev/ttyACM0; baud 19200; timeout 4.00
>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of
>> console successful
>> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware type
>> is 17
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service
>> weewx.engine.StdConvert
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: StdConvert target unit
>> is 0x1
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Finished loading service
>> weewx.engine.StdConvert
>> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service
>> weewx.engine.StdCalibrate
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service
>> weewx.engine.StdCalibrate
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service
>> weewx.engine.StdQC
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service
>> weewx.engine.StdQC
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service
>> weewx.wxservices.StdWXCalculate
>> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following
>> values will be calculated: barometer=prefer_hardware, windchill=prefer_hard
>> ware, dewpoint=prefer_hardware, appTemp=prefer_hardware,
>> rainRate=prefer_hardware, windrun=prefer_hardware,
>> heatindex=prefer_hardware, maxSolar
>> Rad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware,
>> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardwa
>> re, cloudbase=prefer_hardware
>> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following
>> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service
>> weewx.wxservices.StdWXCalculate
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service
>> weewx.engine.StdArchive
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Archive will use data
>> binding wx_binding
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Record generation will
>> be attempted in 'software'
>> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Using archive 

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[gustl319]

Thanks for the fast response.

Am Freitag, 25. November 2016 02:47:18 UTC+1 schrieb Tom Keffer:
>
> Please read the User's Guide, section 3rd party Vantage connectors 
>  and 
> see if that answers your question. 
>

Unfortunately your link didn't answer my question, but changed the problem 
:-(
In the 1st part of log everthing seem fine.

Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Initializing weewx version 
> 3.6.1
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Using Python 2.7.3 
> (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: Platform 
> Linux-3.18.7+-armv6l-with-debian-7.8
> Nov 25 15:54:10 raspberrypi weewx[8932]: engine: pid file is 
> /var/run/weewx.pid
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Using configuration file 
> /etc/weewx/weewx.conf
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Initializing engine
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading station type 
> Vantage (weewx.drivers.vantage)
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: driver version is 3.0.9
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: Opened up serial port 
> /dev/ttyACM0; baud 19200; timeout 4.00
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: gentle wake up of 
> console successful
> Nov 25 15:54:10 raspberrypi weewx[8936]: vantage: _setup; hardware type is 
> 17
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
> weewx.engine.StdConvert
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: StdConvert target unit is 
> 0x1
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.engine.StdConvert
> Nov 25 15:54:10 raspberrypi weewx[8936]: engine: Loading service 
> weewx.engine.StdCalibrate
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.engine.StdCalibrate
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.engine.StdQC
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.engine.StdQC
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.wxservices.StdWXCalculate
> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following values 
> will be calculated: barometer=prefer_hardware, windchill=prefer_hard
> ware, dewpoint=prefer_hardware, appTemp=prefer_hardware, 
> rainRate=prefer_hardware, windrun=prefer_hardware, 
> heatindex=prefer_hardware, maxSolar
> Rad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, 
> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardwa
> re, cloudbase=prefer_hardware
> Nov 25 15:54:11 raspberrypi weewx[8936]: wxcalculate: The following 
> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.wxservices.StdWXCalculate
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.engine.StdArchive
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Archive will use data 
> binding wx_binding
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Record generation will be 
> attempted in 'software'
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Using archive interval of 
> 300 seconds (specified by hardware)
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Use LOOP data in hi/low 
> calculations: 1
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Using binding 
> 'wx_binding' to database 'weewx.sdb'
> Nov 25 15:54:11 raspberrypi weewx[8936]: manager: Starting backfill of 
> daily summaries
> Nov 25 15:54:11 raspberrypi weewx[8936]: manager: Daily summaries up to 
> date
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.engine.StdArchive
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.restx.StdStationRegistry
> Nov 25 15:54:11 raspberrypi weewx[8936]: restx: StationRegistry: 
> Registration not requested.
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.restx.StdStationRegistry
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.restx.StdWunderground
> Nov 25 15:54:11 raspberrypi weewx[8936]: restx: Wunderground: Posting not 
> enabled.
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.restx.StdWunderground
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.restx.StdPWSweather
> Nov 25 15:54:11 raspberrypi weewx[8936]: restx: PWSweather: Posting not 
> enabled.
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.restx.StdPWSweather
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Loading service 
> weewx.restx.StdCWOP
> Nov 25 15:54:11 raspberrypi weewx[8936]: restx: CWOP: Posting not enabled.
> Nov 25 15:54:11 raspberrypi weewx[8936]: engine: Finished loading service 
> weewx.restx.StdCWOP

Re: [weewx-user] Dekay's DavisRFM69 lib without RTC

[Thomas Keffer]

Please read the User's Guide, section 3rd party Vantage connectors
 and see
if that answers your question. If not, come back, but please post the log.

Another question: I see bursts of 'Requesting 200 LOOP packets' in debug
> mode after starting. Is this normal behavior?


Yes. This is how the data gets pulled off the console.

-tk

On Thu, Nov 24, 2016 at 1:54 PM, gustl319  wrote:

> Hi there,
>
> I have a Vantage Vue. On an Adafruit Feather I run Dekay's lib wich
> receives the Vantage packets and seams to work fine. Weewx runs on a Raspi
> with USB to feather. Weewx works well with Simulator. With Vantage I get
> 'less than final timestamp' messages and no records are stored. I assume
> this is because Feather has no RTC and I faked the RTC with a constant
> time.
> Is it possible to configure weewx to use local timestamps with Vantage
> data or to ignore the difference in time?
>
> Another question: I see bursts of 'Requesting 200 LOOP packets' in debug
> mode after starting. Is this normal behavior?
>
>  Thanks and greetings from Bavaria
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.