Re: [weewx-user] Help requested with mosquitto broker
I copied the example mosquitto.conf to /etc/mosquitto then added these lines: listener 1883 allow_anonymous true and now the broker is working again. Thanks very much for the help. On Monday, December 27, 2021 at 11:37:59 AM UTC-7 Greg Troxel wrote: > > Timothy Buchanan writes: > > > When I start mosquitto manually, it will work only locally, that is, > from > > one instance of terminal to another, but will not pick up subscribed > > messages published by a device on the same LAN. Do these error messages > on > > install tell me how to troubleshoot mosquitto? Thanks for any help. > > As Karen says, this is probably due to a change in default behavior for > mosquitto 2. Basically, it's a bug for a program to listen on the > network by default, when it can make sense to only be on localhost. > Certainly one can make mosquitto 2.0.x listen on the network beyond > localhost. > > It sounds like you do not have a configuration file and have not > configured authentication or an explicit listener. Basically, don't do > that - read the docs and set up mosquitto intentionally. > > > Note the man page > > -p, --port > Listen on the port specified. May be specified up to 10 times to > open multiple sockets listening on different ports. > > Important > In version 1.6.x and earlier, the listener defined by -p (or > the default port of 1883) would be bound to all interfaces and > so be accessible from any network. It could also be used in > combination with -c. > > From version 2.0 onwards, the listeners defined with -p are > bound to the loopback interface only, and so can only be > connected to from the local machine. If both -p is used and a > listener is defined in a configuration file, then the -p > options are IGNORED. > > See also ChangeLog.txt in the sources > > 2.0.0 - 2020-12-03 > == > > Breaking changes: > > - When the Mosquitto broker is run without configuring any listeners it > will > now bind to the loopback interfaces 127.0.0.1 and/or ::1. This means that > only connections from the local host will be possible. > > - All listeners now default to `allow_anonymous false` unless explicitly > set > to true in the configuration file. This means that when configuring a > listener the user must either configure an authentication and access > control > method, or set `allow_anonymous true`. When the broker is run without a > configured listener, and so binds to the loopback interface, anonymous > connections are allowed. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c4887d55-13eb-45a7-8ef2-f20a65069d8en%40googlegroups.com.
[weewx-user] Help requested with mosquitto broker
Perhaps this should go to a different forum, but many people here have experience with mosquitto. I'm running buster on a pi 4 model B. I was using MQTTSubscribe and when it stopped working I found that the mosquitto broker had stopped. I decided to purge mosquitto and re-install, but I got these errors: Setting up mosquitto (2.0.12-0mosquitto1~buster1) ... Job for mosquitto.service failed because a timeout was exceeded. See "systemctl status mosquitto.service" and "journalctl -xe" for details. invoke-rc.d: initscript mosquitto, action "start" failed. ● mosquitto.service - Mosquitto MQTT Broker daemon Loaded: loaded (/etc/systemd/system/mosquitto.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: timeout) since Sun 2021-12-19 13:41:03 MST; 54ms ago Process: 1274 ExecStart=/usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf -d (code=exited, status=0/SUCCESS) dpkg: error processing package mosquitto (--configure): installed mosquitto package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: mosquitto E: Sub-process /usr/bin/dpkg returned an error code (1) When I start mosquitto manually, it will work only locally, that is, from one instance of terminal to another, but will not pick up subscribed messages published by a device on the same LAN. Do these error messages on install tell me how to troubleshoot mosquitto? Thanks for any help. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ff0ddef8-2b0b-4daf-ae63-7d9cb37d8837n%40googlegroups.com.
Re: [weewx-user] Cloud Base appearing, why?
Thanks; I didn't realize this was calculated. I've removed it from my skin since the value is not meaningful. Yesterday, for example, skies were clear all day but the reported cloud base was around 15000 feet. On Thursday, November 12, 2020 at 4:12:59 PM UTC-7 tke...@gmail.com wrote: > Cloudbase is a calculated quantity (like windchill), not a measured > quantity. It is a function of temperature, humidity, altitude. Don't know > why you didn't see it before. > > Is it a problem? > > On Thu, Nov 12, 2020 at 2:55 PM Timothy Buchanan > wrote: > >> The upgrade was from 4.1 to 4.2. Weewx.conf was not changed. I have been >> using the extended schema for a month or more before this upgrade, with no >> problems. I do not understand why a value for Cloud Base should suddenly >> appear, since I don't have any sensor that would provide a value and >> cloudBase is not referenced in any extension I use. It has been and should >> be null in the database, but it is not. >> >> On Thursday, November 12, 2020 at 8:27:23 AM UTC-7 tke...@gmail.com >> wrote: >> >>> You didn't give much detail about your upgrade. From what version? To >>> what version? Did you keep your old weewx.conf, or accept the installer's >>> offer to install a new one? >>> >>> Starting with V4.0, cloudbase was included in the list of calculations >>> to be performed in weewx.conf. However, this would only affect you if you >>> installed a new version of weewx.conf. If you kept your old version (the >>> default), the same calculations as before the upgrade would be performed. >>> >>> V4.0 also introduced the "wview_extended" schema, which has a slot for >>> cloudbase. Again, this would only affect you if you changed database >>> schemas --- old schemas would act as before. >>> >>> Is there a problem? >>> >>> -tk >>> >>> >>> On Thu, Nov 12, 2020 at 6:36 AM Timothy Buchanan >>> wrote: >>> >>>> Following an apt upgrade, Cloud Base values have begun appearing in my >>>> database and skin. I have never had a cloud sensor. I am using the >>>> WeatherFlow driver and an extension for the Ecowitt sensors. Thanks for >>>> any >>>> info on 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+...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/33804ba5-be75-4787-b840-2bc8744833f7n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/weewx-user/33804ba5-be75-4787-b840-2bc8744833f7n%40googlegroups.com?utm_medium=email_source=footer> >>>> . >>>> >>> -- >> 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/c5590c76-c65b-4505-9677-7a07054ca351n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/c5590c76-c65b-4505-9677-7a07054ca351n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/1b868171-2d55-424b-bf2a-85ecd1194b42n%40googlegroups.com.
Re: [weewx-user] Cloud Base appearing, why?
The upgrade was from 4.1 to 4.2. Weewx.conf was not changed. I have been using the extended schema for a month or more before this upgrade, with no problems. I do not understand why a value for Cloud Base should suddenly appear, since I don't have any sensor that would provide a value and cloudBase is not referenced in any extension I use. It has been and should be null in the database, but it is not. On Thursday, November 12, 2020 at 8:27:23 AM UTC-7 tke...@gmail.com wrote: > You didn't give much detail about your upgrade. From what version? To what > version? Did you keep your old weewx.conf, or accept the installer's offer > to install a new one? > > Starting with V4.0, cloudbase was included in the list of calculations to > be performed in weewx.conf. However, this would only affect you if you > installed a new version of weewx.conf. If you kept your old version (the > default), the same calculations as before the upgrade would be performed. > > V4.0 also introduced the "wview_extended" schema, which has a slot for > cloudbase. Again, this would only affect you if you changed database > schemas --- old schemas would act as before. > > Is there a problem? > > -tk > > > On Thu, Nov 12, 2020 at 6:36 AM Timothy Buchanan > wrote: > >> Following an apt upgrade, Cloud Base values have begun appearing in my >> database and skin. I have never had a cloud sensor. I am using the >> WeatherFlow driver and an extension for the Ecowitt sensors. Thanks for any >> info on 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+...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/33804ba5-be75-4787-b840-2bc8744833f7n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/33804ba5-be75-4787-b840-2bc8744833f7n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c5590c76-c65b-4505-9677-7a07054ca351n%40googlegroups.com.
[weewx-user] Cloud Base appearing, why?
Following an apt upgrade, Cloud Base values have begun appearing in my database and skin. I have never had a cloud sensor. I am using the WeatherFlow driver and an extension for the Ecowitt sensors. Thanks for any info on 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/33804ba5-be75-4787-b840-2bc8744833f7n%40googlegroups.com.
[weewx-user] Re: Using MQTT Subscribe
The use_topic_as_fieldname=true option gives an error. Can't use it; don't need it with non-nested topics. Not being able to define units is more important as it makes it more difficult to format for display. It'd be nice to have that working, but I can use this as is. Thanks again for your work. On Monday, October 12, 2020 at 11:29:34 AM UTC-6 bell...@gmail.com wrote: > Agreed, two separate problems. > Not yet sure about the units problem. But, you don’t need that option. I > opened an issue to dig into it when I have time. > The second is because it is an invalid configuration. Have you tried the > snippet that is in my last post? Namely, > > [[topics]] > # Units for MQTT payloads without unit value. > # Valid values: US, METRIC, METRICWX > # Default is: US > unit_system = US > ignore_start_time = true > ignore_end_time = true > use_topic_as_fieldname = true > > # The first topic > [[[snowDepth]]] > > Or with nested topics, > > [[topics]] > # Units for MQTT payloads without unit value. > # Valid values: US, METRIC, METRICWX > # Default is: US > unit_system = US > ignore_start_time = true > ignore_end_time = true > use_topic_as_fieldname = true > > # The first topic > [[[snow/snowDepth]]] > name = snowDepth > > These would be the simplest to start with. > And again, full logs instead of snippets would make this so much easier. > rich > > On Monday, 12 October 2020 at 12:57:25 UTC-4 timothye...@gmail.com wrote: > >> See attached. >> >> On Monday, October 12, 2020 at 9:36:08 AM UTC-6 bell...@gmail.com wrote: >> >>> >>> Well, I don’t understand how that configuration even got that far. I >>> would have expected the previous error. But just seeing log snippets is >>> like walking around blindfolded. Base on your last config snippet, replace >>> it with >>> >>> The topics to subscribe to. >>> [[topics]] >>> # Units for MQTT payloads without unit value. >>> # Valid values: US, METRIC, METRICWX >>> # Default is: US >>> unit_system = US >>> ignore_start_time = true >>> ignore_end_time = true >>> use_topic_as_fieldname = true >>> >>> # The first topic >>> # MQTT Topic >>> [[[snowDepth]]] >>> >>> This last error has to do with trying to convert the units of snowDepth. >>> Either it WeeWX does not fully support that, or more likely I am doing >>> something wrong. But since everything is in the US unit_system, you don’t >>> need to specify units at the field level. >>> >>> On Monday, 12 October 2020 at 10:38:14 UTC-4 timothye...@gmail.com >>> wrote: >>> >>>> I decided to try simplifying the topic to just snowDepth, as this: >>>> >>>> The topics to subscribe to. >>>> [[topics]] >>>> # Units for MQTT payloads without unit value. >>>> # Valid values: US, METRIC, METRICWX >>>> # Default is: US >>>> unit_system = US >>>> ignore_start_time = true >>>> ignore_end_time = true >>>> use_topic_as_fieldname = true >>>> >>>> # The first topic >>>> # MQTT Topic >>>> [[[snowDepth]]] >>>> # MQTT name >>>> snowDepth >>>> # weewx name >>>> name = snowDepth >>>> ignore = false >>>> contains_total = false >>>> conversion_type = float >>>> units = inch >>>> >>>> when I publish 2.5 to snowDepth, I get this error in syslog: >>>> >>>> Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG user.MQTTSubscribe: >>>> (Service) MessageCallbackProvider data-> incoming topic: snowDepth, QOS: >>>> 0, >>>> retain: 0, payload: b'2.5' >>>> Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG weewx.units: Unable to >>>> convert from inch to None >>>> Oct 12 08:12:52 raspberrypi weewx[29222] ERROR user.MQTTSubscribe: >>>> (Service) MessageCallbackProvider on_message_individual failed with: None >>>> Oct 12 08:12:52 r
[weewx-user] Re: Using MQTT Subscribe
See attached. On Monday, October 12, 2020 at 9:36:08 AM UTC-6 bell...@gmail.com wrote: > > Well, I don’t understand how that configuration even got that far. I would > have expected the previous error. But just seeing log snippets is like > walking around blindfolded. Base on your last config snippet, replace it > with > > The topics to subscribe to. > [[topics]] > # Units for MQTT payloads without unit value. > # Valid values: US, METRIC, METRICWX > # Default is: US > unit_system = US > ignore_start_time = true > ignore_end_time = true > use_topic_as_fieldname = true > > # The first topic > # MQTT Topic > [[[snowDepth]]] > > This last error has to do with trying to convert the units of snowDepth. > Either it WeeWX does not fully support that, or more likely I am doing > something wrong. But since everything is in the US unit_system, you don’t > need to specify units at the field level. > > On Monday, 12 October 2020 at 10:38:14 UTC-4 timothye...@gmail.com wrote: > >> I decided to try simplifying the topic to just snowDepth, as this: >> >> The topics to subscribe to. >> [[topics]] >> # Units for MQTT payloads without unit value. >> # Valid values: US, METRIC, METRICWX >> # Default is: US >> unit_system = US >> ignore_start_time = true >> ignore_end_time = true >> use_topic_as_fieldname = true >> >> # The first topic >> # MQTT Topic >> [[[snowDepth]]] >> # MQTT name >> snowDepth >> # weewx name >> name = snowDepth >> ignore = false >> contains_total = false >> conversion_type = float >> units = inch >> >> when I publish 2.5 to snowDepth, I get this error in syslog: >> >> Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG user.MQTTSubscribe: >> (Service) MessageCallbackProvider data-> incoming topic: snowDepth, QOS: 0, >> retain: 0, payload: b'2.5' >> Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG weewx.units: Unable to >> convert from inch to None >> Oct 12 08:12:52 raspberrypi weewx[29222] ERROR user.MQTTSubscribe: >> (Service) MessageCallbackProvider on_message_individual failed with: None >> Oct 12 08:12:52 raspberrypi weewx[29222] ERROR user.MQTTSubscribe: >> (Service) MessageCallbackProvider Ignoring topic=snowDepth and >> payload=b'2.5' >> >> Could you perhaps post a working configuration file, any topic, any unit, >> etc. just one that works on your weewx and I will plug it in and see what >> happens? >> >> On Sunday, October 11, 2020 at 7:27:15 PM UTC-6 Timothy Buchanan wrote: >> >>> See attached. >>> >>> On Sunday, October 11, 2020 at 5:45:43 PM UTC-6 bell...@gmail.com wrote: >>> >>>> Sorry, I didn’t get the config quite right. I don’t subscribe to >>>> ‘individual’ topics, so this is untested, but should work. If it doesn’t, >>>> I’ll spin up a debug environment to figure it out. >>>> [[topics]] >>>> Keep the current settings, unit_system, ignore_start_time, >>>> ignore_end_time, etc. >>>> >>>> # The next option will take the tail end of the topic and use it as >>>> the MQTT field name >>>> # So, if the topic is snow/snowDepth, the MQTT field name is snowDepth >>>> # Only valid when the payload is type ‘individual’ >>>> use_topic_as_fieldname = true >>>> [[[snow/snowDepth]]] >>>> # Because snowDepth is the WeeWX name and the defaults work for >>>> you, nothing else is needed. >>>>[[[snow/snowRate]]] >>>> # Not sure, but the defaults should probably work here... >>>> >>>> Again, if this doesn’t work; post the log and I’ll spin up a debug >>>> environment to figure out what is going on. >>>> rich >>>> On Sunday, 11 October 2020 at 16:43:58 UTC-4 timothye...@gmail.com >>>> wrote: >>>> >>>>> After moving the ignore lines, I am happy to report that the time >>>>> problem is solved; that is, it is no longer rejecting the topic. However, >>>>> it is still not making it into the database. I think this is because it >>>>> is >>>>> not converting from snow/snowDepth to snowDepth. S
[weewx-user] Re: Using MQTT Subscribe
I decided to try simplifying the topic to just snowDepth, as this: The topics to subscribe to. [[topics]] # Units for MQTT payloads without unit value. # Valid values: US, METRIC, METRICWX # Default is: US unit_system = US ignore_start_time = true ignore_end_time = true use_topic_as_fieldname = true # The first topic # MQTT Topic [[[snowDepth]]] # MQTT name snowDepth # weewx name name = snowDepth ignore = false contains_total = false conversion_type = float units = inch when I publish 2.5 to snowDepth, I get this error in syslog: Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG user.MQTTSubscribe: (Service) MessageCallbackProvider data-> incoming topic: snowDepth, QOS: 0, retain: 0, payload: b'2.5' Oct 12 08:12:52 raspberrypi weewx[29222] DEBUG weewx.units: Unable to convert from inch to None Oct 12 08:12:52 raspberrypi weewx[29222] ERROR user.MQTTSubscribe: (Service) MessageCallbackProvider on_message_individual failed with: None Oct 12 08:12:52 raspberrypi weewx[29222] ERROR user.MQTTSubscribe: (Service) MessageCallbackProvider Ignoring topic=snowDepth and payload=b'2.5' Could you perhaps post a working configuration file, any topic, any unit, etc. just one that works on your weewx and I will plug it in and see what happens? On Sunday, October 11, 2020 at 7:27:15 PM UTC-6 Timothy Buchanan wrote: > See attached. > > On Sunday, October 11, 2020 at 5:45:43 PM UTC-6 bell...@gmail.com wrote: > >> Sorry, I didn’t get the config quite right. I don’t subscribe to >> ‘individual’ topics, so this is untested, but should work. If it doesn’t, >> I’ll spin up a debug environment to figure it out. >> [[topics]] >> Keep the current settings, unit_system, ignore_start_time, >> ignore_end_time, etc. >> >> # The next option will take the tail end of the topic and use it as the >> MQTT field name >> # So, if the topic is snow/snowDepth, the MQTT field name is snowDepth >> # Only valid when the payload is type ‘individual’ >> use_topic_as_fieldname = true >> [[[snow/snowDepth]]] >> # Because snowDepth is the WeeWX name and the defaults work for you, >> nothing else is needed. >>[[[snow/snowRate]]] >> # Not sure, but the defaults should probably work here... >> >> Again, if this doesn’t work; post the log and I’ll spin up a debug >> environment to figure out what is going on. >> rich >> On Sunday, 11 October 2020 at 16:43:58 UTC-4 timothye...@gmail.com wrote: >> >>> After moving the ignore lines, I am happy to report that the time >>> problem is solved; that is, it is no longer rejecting the topic. However, >>> it is still not making it into the database. I think this is because it is >>> not converting from snow/snowDepth to snowDepth. See attached syslog >>> extract and weewx.conf for section where topic is configured. Is there a >>> mistake in this topic configuration? >>> >>> On Sunday, October 11, 2020 at 11:26:27 AM UTC-6 bell...@gmail.com >>> wrote: >>> >>>> I've run both extensions off and on, so I don't think there is any >>>> conflict. The root-root cause is time skew between your pi and weather >>>> station and MQTTSubscribe being a bit overly aggressive on its quality >>>> control. Setting ignore_start_time and ignore_end_time should turn this >>>> off >>>> completely. Since the incoming data has no dateTime, this seems the most >>>> logical approach. >>>> >>>> I noticed in the latest attached config, those options are in the wrong >>>> place. Move them under [[topics]] after >>>> unit_system = US >>>> ignore_start_time = true >>>> ignore_end_time = true >>>> Also, Ignore_end_time has a capital "I". >>>> If it is still not working, please attach the log from startup. That >>>> way we can see how the options are being processed. >>>> I think we are real close. -rich >>>> >>>> On Sunday, 11 October 2020 at 12:20:32 UTC-4 timothye...@gmail.com >>>> wrote: >>>> >>>>> I used wee_extension to uninstall the old version then install the >>>>> new. I used the configuration as shown in the attached file. When I >>>>> publish >>>>> to a topic, Topic Manager still ignores it as outside of interval (syslog >>>>> extract in attached file). >>>>> >&
[weewx-user] Re: Using MQTT Subscribe
[[topics]] >>>>>>>> # Units for MQTT payloads without unit value. >>>>>>>> # Valid values: US, METRIC, METRICWX >>>>>>>> # Default is: US >>>>>>>> unit_system = US >>>>>>>> ignore_start_time = true >>>>>>>> Ignore_end_time = true >>>>>>>> >>>>>>>> but I still get this: >>>>>>>> >>>>>>>> Oct 9 20:38:29 raspberrypi weewx[30461] INFO weewx.restx: MQTT: >>>>>>>> Published record 2020-10-09 20:38:47 MDT (1602297527) >>>>>>>> Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) MessageCallbackProvider data-> incoming topic: >>>>>>>> snow/snowDepth, >>>>>>>> QOS: 0, retain: 0, payload: b'7' >>>>>>>> Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) TopicManager data-> incoming snow/snowDepth: snow/snowDepth: >>>>>>>> 7.0 >>>>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) TopicManager data-> outgoing snow/snowDepth: dateTime: >>>>>>>> 1602297510.2596123, snow/snowDepth: 7.0, usUnits: 1 >>>>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] INFO user.MQTTSubscribe: >>>>>>>> (Service) TopicManager ignoring record outside of interval >>>>>>>> 1602297510.259612 1602297529.00 1602297510.259612 dateTime: >>>>>>>> 1602297510.2596123, snow/snowDepth: 7.0, usUnits: 1 >>>>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) TopicManager data-> outgoing accumulated snow/snowDepth: >>>>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) data-> final packet is 2020-10-09 20:38:49 MDT (1602297529): >>>>>>>> avg_distance: 0, dateTime: 1602297529, lightning_strikes: 0, >>>>>>>> outHumidity: >>>>>>>> 23, outTemp: 13.34, outTempBatteryStatus: 2.919, pressure: 744.7, >>>>>>>> usUnits: >>>>>>>> 17 >>>>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] INFO weewx.restx: MQTT: >>>>>>>> Published record 2020-10-09 20:38:49 MDT (1602297529) >>>>>>>> Oct 9 20:38:32 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>>>> (Service) data-> final packet is 2020-10-09 20:38:50 MDT (1602297530): >>>>>>>> dateTime: 1602297530, usUnits: 17, windDir: 336, windSpeed: 0.72 >>>>>>>> Oct 9 20:38:32 raspberrypi weewx[30461] INFO weewx.restx: MQTT: >>>>>>>> Published record 2020-10-09 20:38:50 MDT (1602297530) >>>>>>>> >>>>>>>> On Friday, October 9, 2020 at 5:13:41 PM UTC-6 bell...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Ah, crap. This has to do with an attempt to quality control data >>>>>>>>> by time. Next major release, I really need to rework it... >>>>>>>>> Since you have individual payloads (no timestamp from the origin) >>>>>>>>> add the following under [[topics]] >>>>>>>>> ignore_start_time = true >>>>>>>>> Ignore_end_time = true >>>>>>>>> >>>>>>>>> We are getting close. Sorry for the pain. >>>>>>>>> rich >>>>>>>>> >>>>>>>>> >>>>>>>>> On Friday, 9 October 2020 at 18:36:27 UTC-4 timothye...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> syslog extract posted. weewx is loading the service, though it >>>>>>>>>> also seems to subscribe to the data which MQTT is publishing from >>>>>>>>>> weewx. >>>>>>>>>> the second section shows that subscribe receives the data I >>>>>>>>>> published from >>>>>>>>>> the terminal (6 inches of snow), but rejects
[weewx-user] Re: Using MQTT Subscribe
spberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>> (Service) TopicManager data-> outgoing accumulated snow/snowDepth: >>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>> (Service) data-> final packet is 2020-10-09 20:38:49 MDT (1602297529): >>>>>> avg_distance: 0, dateTime: 1602297529, lightning_strikes: 0, >>>>>> outHumidity: >>>>>> 23, outTemp: 13.34, outTempBatteryStatus: 2.919, pressure: 744.7, >>>>>> usUnits: >>>>>> 17 >>>>>> Oct 9 20:38:31 raspberrypi weewx[30461] INFO weewx.restx: MQTT: >>>>>> Published record 2020-10-09 20:38:49 MDT (1602297529) >>>>>> Oct 9 20:38:32 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: >>>>>> (Service) data-> final packet is 2020-10-09 20:38:50 MDT (1602297530): >>>>>> dateTime: 1602297530, usUnits: 17, windDir: 336, windSpeed: 0.72 >>>>>> Oct 9 20:38:32 raspberrypi weewx[30461] INFO weewx.restx: MQTT: >>>>>> Published record 2020-10-09 20:38:50 MDT (1602297530) >>>>>> >>>>>> On Friday, October 9, 2020 at 5:13:41 PM UTC-6 bell...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Ah, crap. This has to do with an attempt to quality control data by >>>>>>> time. Next major release, I really need to rework it... >>>>>>> Since you have individual payloads (no timestamp from the origin) >>>>>>> add the following under [[topics]] >>>>>>> ignore_start_time = true >>>>>>> Ignore_end_time = true >>>>>>> >>>>>>> We are getting close. Sorry for the pain. >>>>>>> rich >>>>>>> >>>>>>> >>>>>>> On Friday, 9 October 2020 at 18:36:27 UTC-4 timothye...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> syslog extract posted. weewx is loading the service, though it also >>>>>>>> seems to subscribe to the data which MQTT is publishing from weewx. >>>>>>>> the >>>>>>>> second section shows that subscribe receives the data I published from >>>>>>>> the >>>>>>>> terminal (6 inches of snow), but rejects it as outside of interval. Is >>>>>>>> there an entry to be made somewhere to sync incoming data? I note that >>>>>>>> another extension I use (GW1000) needed dateTime = datetime in a field >>>>>>>> map >>>>>>>> to work properly. >>>>>>>> >>>>>>>> On Friday, October 9, 2020 at 2:54:56 PM UTC-6 bell...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> That could be simplified, but looks like it should work. The >>>>>>>>> quickest and easiest way to proceed is to set debug to 1, restart >>>>>>>>> WeeWX, >>>>>>>>> let it run through an archive cycle during which you published to >>>>>>>>> that >>>>>>>>> topic and then post the log. >>>>>>>>> >>>>>>>>> Re: snowBatteryStatus - The units config option is only needed if >>>>>>>>> the field units do not match the units expected by the unit_system. >>>>>>>>> So >>>>>>>>> eliminating will at least get the data in the DB. >>>>>>>>> Note, units is not needed for snowDepth because inches is the >>>>>>>>> Units for that field in the US unit_system. >>>>>>>>> rich >>>>>>>>> On Friday, 9 October 2020 at 14:23:01 UTC-4 timothye...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I've attached a syslog extract showing where weewx crashed. it >>>>>>>>>> seems that "volt" is an invalid unit for my topic. i don't know why >>>>>>>>>> but for >>>>>>>>>> now I commented out that topic and its parameters. Now, weewx will >>>>>>>>>> continue >>>&g
[weewx-user] Re: Using MQTT Subscribe
osted. weewx is loading the service, though it also >>>>>> seems to subscribe to the data which MQTT is publishing from weewx. the >>>>>> second section shows that subscribe receives the data I published from >>>>>> the >>>>>> terminal (6 inches of snow), but rejects it as outside of interval. Is >>>>>> there an entry to be made somewhere to sync incoming data? I note that >>>>>> another extension I use (GW1000) needed dateTime = datetime in a field >>>>>> map >>>>>> to work properly. >>>>>> >>>>>> On Friday, October 9, 2020 at 2:54:56 PM UTC-6 bell...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> That could be simplified, but looks like it should work. The >>>>>>> quickest and easiest way to proceed is to set debug to 1, restart >>>>>>> WeeWX, >>>>>>> let it run through an archive cycle during which you published to that >>>>>>> topic and then post the log. >>>>>>> >>>>>>> Re: snowBatteryStatus - The units config option is only needed if >>>>>>> the field units do not match the units expected by the unit_system. So >>>>>>> eliminating will at least get the data in the DB. >>>>>>> Note, units is not needed for snowDepth because inches is the Units >>>>>>> for that field in the US unit_system. >>>>>>> rich >>>>>>> On Friday, 9 October 2020 at 14:23:01 UTC-4 timothye...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> I've attached a syslog extract showing where weewx crashed. it >>>>>>>> seems that "volt" is an invalid unit for my topic. i don't know why >>>>>>>> but for >>>>>>>> now I commented out that topic and its parameters. Now, weewx will >>>>>>>> continue >>>>>>>> running when subscribe is enabled, but subscribed topics are not being >>>>>>>> posted to the database. Here is the first topic in weewx.conf: >>>>>>>> >>>>>>>> # The first topic >>>>>>>> # MQTT Topic >>>>>>>> [[[snow/snowDepth]]] >>>>>>>> # MQTT name >>>>>>>> snowDepth >>>>>>>> # weewx name >>>>>>>> name = snowDepth >>>>>>>> ignore = false >>>>>>>> contains_total = false >>>>>>>> conversion_type = float >>>>>>>> units = inch >>>>>>>> >>>>>>>> I used a terminal to publish "6" to snow/snowDepth on Mosquitto. >>>>>>>> Another terminal window command to subscribe to snow/snowDepth >>>>>>>> received the >>>>>>>> "6" but the database entries for snowDepth are null. Is this >>>>>>>> configuration >>>>>>>> of topics still not correct. Thanks. >>>>>>>> On Tuesday, October 6, 2020 at 1:43:31 PM UTC-6 Timothy Buchanan >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks, Rich. I'll try it when I get back. I'll be in our second >>>>>>>>> home for a few days: going to the gun range and the clothing-optional >>>>>>>>> resort (not at the same time!). >>>>>>>>> >>>>>>>>> On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 bell...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> So, the [[[first/topic]]] are meant to be replaced with the >>>>>>>>>> actual topic. So it would be something like this >>>>>>>>>> ``` >>>>>>>>>> [[Topics]] >>>>>>>>>> [[[topic name that snowDepth is published on]]] >>>>>>>>>> topic name that snowDepth is published on >>>>>>>>>> name = snowDepth >>>>>>>>>> [[[topic name that snowRate is published on]]] >>>>>>>>>> topic name that snowRate is published on >>>>>>>&g
[weewx-user] Re: Using MQTT Subscribe
ld in the US unit_system. >>>>> rich >>>>> On Friday, 9 October 2020 at 14:23:01 UTC-4 timothye...@gmail.com >>>>> wrote: >>>>> >>>>>> I've attached a syslog extract showing where weewx crashed. it seems >>>>>> that "volt" is an invalid unit for my topic. i don't know why but for >>>>>> now I >>>>>> commented out that topic and its parameters. Now, weewx will continue >>>>>> running when subscribe is enabled, but subscribed topics are not being >>>>>> posted to the database. Here is the first topic in weewx.conf: >>>>>> >>>>>> # The first topic >>>>>> # MQTT Topic >>>>>> [[[snow/snowDepth]]] >>>>>> # MQTT name >>>>>> snowDepth >>>>>> # weewx name >>>>>> name = snowDepth >>>>>> ignore = false >>>>>> contains_total = false >>>>>> conversion_type = float >>>>>> units = inch >>>>>> >>>>>> I used a terminal to publish "6" to snow/snowDepth on Mosquitto. >>>>>> Another terminal window command to subscribe to snow/snowDepth received >>>>>> the >>>>>> "6" but the database entries for snowDepth are null. Is this >>>>>> configuration >>>>>> of topics still not correct. Thanks. >>>>>> On Tuesday, October 6, 2020 at 1:43:31 PM UTC-6 Timothy Buchanan >>>>>> wrote: >>>>>> >>>>>>> Thanks, Rich. I'll try it when I get back. I'll be in our second >>>>>>> home for a few days: going to the gun range and the clothing-optional >>>>>>> resort (not at the same time!). >>>>>>> >>>>>>> On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 bell...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> So, the [[[first/topic]]] are meant to be replaced with the actual >>>>>>>> topic. So it would be something like this >>>>>>>> ``` >>>>>>>> [[Topics]] >>>>>>>> [[[topic name that snowDepth is published on]]] >>>>>>>> topic name that snowDepth is published on >>>>>>>> name = snowDepth >>>>>>>> [[[topic name that snowRate is published on]]] >>>>>>>> topic name that snowRate is published on >>>>>>>> name = snowRate >>>>>>>> ``` >>>>>>>> The duplication is an artifact of dealing with json and keyword >>>>>>>> payloads. The ```use_topic_as_fieldname``` option can be used to >>>>>>>> make the config a bit prettier. >>>>>>>> ``` >>>>>>>> [[Topics]] >>>>>>>> use_topic_as_fieldname = true >>>>>>>> [[[topic name that snowDepth is published on]]] >>>>>>>> name = snowDepth >>>>>>>> [[[topic name that snowRate is published on]]] >>>>>>>> name = snowRate >>>>>>>> ``` >>>>>>>> Note, if snowDepth is actually published on the topic snowDepth, >>>>>>>> the ```name``` option can be left off. >>>>>>>> I don’t think that you want to set contains_total=true for >>>>>>>> snowDepth. This is used when the field contains a total and it needs >>>>>>>> to be >>>>>>>> converted into an increment for WeeWX. >>>>>>>> >>>>>>>> I’ll work on clarifying the wiki. >>>>>>>> >>>>>>>> With that said, it shouldn’t have broken WeeWX. If you are up for >>>>>>>> it, before changing the config, setting debug=1, restarting WeeWX for >>>>>>>> a >>>>>>>> couple of archive intervals and attaching the log would be appreciated >>>>>>>> . >>>>>>>> >>>>>>>> rich >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, 6 October 2020 at 13:28:34 UTC-4 timothye...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Attached is the extension material that I put into weewx.conf. But >>>>>>>>> when I set enable = true, weewx stops archiving data. Is there an >>>>>>>>> error in >>>>>>>>> this configuration, or could subscribe be incompatible with another >>>>>>>>> service? I'm using the Weatherflowudp driver with mqtt and GW1000 >>>>>>>>> extensions. >>>>>>>>> >>>>>>>>> On Tuesday, October 6, 2020 at 9:17:07 AM UTC-6 Timothy Buchanan >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks, Rich, I should be able to edit weewx.conf based on the >>>>>>>>>> example at the bottom of that page. >>>>>>>>>> >>>>>>>>>> I am using an ESP8266 board with an ultrasonic sensor and a >>>>>>>>>> temperature sensor (to calibrate the speed of sound), and >>>>>>>>>> programming in >>>>>>>>>> the Arduino IDE. I'll 3D print a case and mount it above my deck. >>>>>>>>>> The >>>>>>>>>> materials cost about $15. >>>>>>>>>> >>>>>>>>>> I'd be happy to post the code here, under a new topic, once I get >>>>>>>>>> it working. >>>>>>>>>> >>>>>>>>>> Timothy >>>>>>>>>> >>>>>>>>>> On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 >>>>>>>>>> storm...@gmail.com wrote: >>>>>>>>>> >>>>>>>>>>> What type of sensor are you using for measuring snow depth? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/5b933f95-3d51-4413-b92e-c016f57b4ae6n%40googlegroups.com.
[weewx-user] Re: Using MQTT Subscribe
I added those this way: # The topics to subscribe to. [[topics]] # Units for MQTT payloads without unit value. # Valid values: US, METRIC, METRICWX # Default is: US unit_system = US ignore_start_time = true Ignore_end_time = true but I still get this: Oct 9 20:38:29 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published record 2020-10-09 20:38:47 MDT (1602297527) Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) MessageCallbackProvider data-> incoming topic: snow/snowDepth, QOS: 0, retain: 0, payload: b'7' Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> incoming snow/snowDepth: snow/snowDepth: 7.0 Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> outgoing snow/snowDepth: dateTime: 1602297510.2596123, snow/snowDepth: 7.0, usUnits: 1 Oct 9 20:38:31 raspberrypi weewx[30461] INFO user.MQTTSubscribe: (Service) TopicManager ignoring record outside of interval 1602297510.259612 1602297529.00 1602297510.259612 dateTime: 1602297510.2596123, snow/snowDepth: 7.0, usUnits: 1 Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> outgoing accumulated snow/snowDepth: Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) data-> final packet is 2020-10-09 20:38:49 MDT (1602297529): avg_distance: 0, dateTime: 1602297529, lightning_strikes: 0, outHumidity: 23, outTemp: 13.34, outTempBatteryStatus: 2.919, pressure: 744.7, usUnits: 17 Oct 9 20:38:31 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published record 2020-10-09 20:38:49 MDT (1602297529) Oct 9 20:38:32 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe: (Service) data-> final packet is 2020-10-09 20:38:50 MDT (1602297530): dateTime: 1602297530, usUnits: 17, windDir: 336, windSpeed: 0.72 Oct 9 20:38:32 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published record 2020-10-09 20:38:50 MDT (1602297530) On Friday, October 9, 2020 at 5:13:41 PM UTC-6 bell...@gmail.com wrote: > > Ah, crap. This has to do with an attempt to quality control data by time. > Next major release, I really need to rework it... > Since you have individual payloads (no timestamp from the origin) add the > following under [[topics]] > ignore_start_time = true > Ignore_end_time = true > > We are getting close. Sorry for the pain. > rich > > > On Friday, 9 October 2020 at 18:36:27 UTC-4 timothye...@gmail.com wrote: > >> syslog extract posted. weewx is loading the service, though it also seems >> to subscribe to the data which MQTT is publishing from weewx. the second >> section shows that subscribe receives the data I published from the >> terminal (6 inches of snow), but rejects it as outside of interval. Is >> there an entry to be made somewhere to sync incoming data? I note that >> another extension I use (GW1000) needed dateTime = datetime in a field map >> to work properly. >> >> On Friday, October 9, 2020 at 2:54:56 PM UTC-6 bell...@gmail.com wrote: >> >>> >>> That could be simplified, but looks like it should work. The quickest >>> and easiest way to proceed is to set debug to 1, restart WeeWX, let it run >>> through an archive cycle during which you published to that topic and then >>> post the log. >>> >>> Re: snowBatteryStatus - The units config option is only needed if the >>> field units do not match the units expected by the unit_system. So >>> eliminating will at least get the data in the DB. >>> Note, units is not needed for snowDepth because inches is the Units for >>> that field in the US unit_system. >>> rich >>> On Friday, 9 October 2020 at 14:23:01 UTC-4 timothye...@gmail.com wrote: >>> >>>> I've attached a syslog extract showing where weewx crashed. it seems >>>> that "volt" is an invalid unit for my topic. i don't know why but for now >>>> I >>>> commented out that topic and its parameters. Now, weewx will continue >>>> running when subscribe is enabled, but subscribed topics are not being >>>> posted to the database. Here is the first topic in weewx.conf: >>>> >>>> # The first topic >>>> # MQTT Topic >>>> [[[snow/snowDepth]]] >>>> # MQTT name >>>> snowDepth >>>> # weewx name >>>> name = snowDepth >>>> ignore = false >>>> contains_total = false >>>> conversion_type = float >>>> units = inch >>>> >>>> I used a terminal to publish "6" to snow/snowDepth on Mosquitto. >>>> A
[weewx-user] Re: Using MQTT Subscribe
syslog extract posted. weewx is loading the service, though it also seems to subscribe to the data which MQTT is publishing from weewx. the second section shows that subscribe receives the data I published from the terminal (6 inches of snow), but rejects it as outside of interval. Is there an entry to be made somewhere to sync incoming data? I note that another extension I use (GW1000) needed dateTime = datetime in a field map to work properly. On Friday, October 9, 2020 at 2:54:56 PM UTC-6 bell...@gmail.com wrote: > > That could be simplified, but looks like it should work. The quickest and > easiest way to proceed is to set debug to 1, restart WeeWX, let it run > through an archive cycle during which you published to that topic and then > post the log. > > Re: snowBatteryStatus - The units config option is only needed if the > field units do not match the units expected by the unit_system. So > eliminating will at least get the data in the DB. > Note, units is not needed for snowDepth because inches is the Units for > that field in the US unit_system. > rich > On Friday, 9 October 2020 at 14:23:01 UTC-4 timothye...@gmail.com wrote: > >> I've attached a syslog extract showing where weewx crashed. it seems that >> "volt" is an invalid unit for my topic. i don't know why but for now I >> commented out that topic and its parameters. Now, weewx will continue >> running when subscribe is enabled, but subscribed topics are not being >> posted to the database. Here is the first topic in weewx.conf: >> >> # The first topic >> # MQTT Topic >> [[[snow/snowDepth]]] >> # MQTT name >> snowDepth >> # weewx name >> name = snowDepth >> ignore = false >> contains_total = false >> conversion_type = float >> units = inch >> >> I used a terminal to publish "6" to snow/snowDepth on Mosquitto. Another >> terminal window command to subscribe to snow/snowDepth received the "6" but >> the database entries for snowDepth are null. Is this configuration of >> topics still not correct. Thanks. >> On Tuesday, October 6, 2020 at 1:43:31 PM UTC-6 Timothy Buchanan wrote: >> >>> Thanks, Rich. I'll try it when I get back. I'll be in our second home >>> for a few days: going to the gun range and the clothing-optional resort >>> (not at the same time!). >>> >>> On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 bell...@gmail.com wrote: >>> >>>> So, the [[[first/topic]]] are meant to be replaced with the actual >>>> topic. So it would be something like this >>>> ``` >>>> [[Topics]] >>>> [[[topic name that snowDepth is published on]]] >>>> topic name that snowDepth is published on >>>> name = snowDepth >>>> [[[topic name that snowRate is published on]]] >>>> topic name that snowRate is published on >>>> name = snowRate >>>> ``` >>>> The duplication is an artifact of dealing with json and keyword >>>> payloads. The ```use_topic_as_fieldname``` option can be used to make >>>> the config a bit prettier. >>>> ``` >>>> [[Topics]] >>>> use_topic_as_fieldname = true >>>> [[[topic name that snowDepth is published on]]] >>>> name = snowDepth >>>> [[[topic name that snowRate is published on]]] >>>> name = snowRate >>>> ``` >>>> Note, if snowDepth is actually published on the topic snowDepth, the >>>> ```name``` option can be left off. >>>> I don’t think that you want to set contains_total=true for snowDepth. >>>> This is used when the field contains a total and it needs to be converted >>>> into an increment for WeeWX. >>>> >>>> I’ll work on clarifying the wiki. >>>> >>>> With that said, it shouldn’t have broken WeeWX. If you are up for it, >>>> before changing the config, setting debug=1, restarting WeeWX for a couple >>>> of archive intervals and attaching the log would be appreciated . >>>> >>>> rich >>>> >>>> >>>> >>>> On Tuesday, 6 October 2020 at 13:28:34 UTC-4 timothye...@gmail.com >>>> wrote: >>>> >>>>> Attached is the extension material that I put into weewx.conf. But >>>>> when I set enable = true, weewx stops archiving data. Is there an error >>>>> in >>>>> this configuration, or could subscribe be incompatible with another >&g
[weewx-user] Re: Using MQTT Subscribe
I've attached a syslog extract showing where weewx crashed. it seems that "volt" is an invalid unit for my topic. i don't know why but for now I commented out that topic and its parameters. Now, weewx will continue running when subscribe is enabled, but subscribed topics are not being posted to the database. Here is the first topic in weewx.conf: # The first topic # MQTT Topic [[[snow/snowDepth]]] # MQTT name snowDepth # weewx name name = snowDepth ignore = false contains_total = false conversion_type = float units = inch I used a terminal to publish "6" to snow/snowDepth on Mosquitto. Another terminal window command to subscribe to snow/snowDepth received the "6" but the database entries for snowDepth are null. Is this configuration of topics still not correct. Thanks. On Tuesday, October 6, 2020 at 1:43:31 PM UTC-6 Timothy Buchanan wrote: > Thanks, Rich. I'll try it when I get back. I'll be in our second home for > a few days: going to the gun range and the clothing-optional resort (not at > the same time!). > > On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 bell...@gmail.com wrote: > >> So, the [[[first/topic]]] are meant to be replaced with the actual topic. >> So it would be something like this >> ``` >> [[Topics]] >> [[[topic name that snowDepth is published on]]] >> topic name that snowDepth is published on >> name = snowDepth >> [[[topic name that snowRate is published on]]] >> topic name that snowRate is published on >> name = snowRate >> ``` >> The duplication is an artifact of dealing with json and keyword payloads. >> The ```use_topic_as_fieldname``` option can be used to make the config a >> bit prettier. >> ``` >> [[Topics]] >> use_topic_as_fieldname = true >> [[[topic name that snowDepth is published on]]] >> name = snowDepth >> [[[topic name that snowRate is published on]]] >> name = snowRate >> ``` >> Note, if snowDepth is actually published on the topic snowDepth, the >> ```name``` option can be left off. >> I don’t think that you want to set contains_total=true for snowDepth. >> This is used when the field contains a total and it needs to be converted >> into an increment for WeeWX. >> >> I’ll work on clarifying the wiki. >> >> With that said, it shouldn’t have broken WeeWX. If you are up for it, >> before changing the config, setting debug=1, restarting WeeWX for a couple >> of archive intervals and attaching the log would be appreciated . >> >> rich >> >> >> >> On Tuesday, 6 October 2020 at 13:28:34 UTC-4 timothye...@gmail.com wrote: >> >>> Attached is the extension material that I put into weewx.conf. But when >>> I set enable = true, weewx stops archiving data. Is there an error in this >>> configuration, or could subscribe be incompatible with another service? I'm >>> using the Weatherflowudp driver with mqtt and GW1000 extensions. >>> >>> On Tuesday, October 6, 2020 at 9:17:07 AM UTC-6 Timothy Buchanan wrote: >>> >>>> Thanks, Rich, I should be able to edit weewx.conf based on the example >>>> at the bottom of that page. >>>> >>>> I am using an ESP8266 board with an ultrasonic sensor and a temperature >>>> sensor (to calibrate the speed of sound), and programming in the Arduino >>>> IDE. I'll 3D print a case and mount it above my deck. The materials cost >>>> about $15. >>>> >>>> I'd be happy to post the code here, under a new topic, once I get it >>>> working. >>>> >>>> Timothy >>>> >>>> On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 storm...@gmail.com >>>> wrote: >>>> >>>>> What type of sensor are you using for measuring snow depth? >>>>> >>>>> >>>>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/886843b0-1a11-4fdc-8dd9-6b1d8cee9f12n%40googlegroups.com. Oct 9 09:47:33 raspberrypi weewx[31856] INFO user.MQTTSubscribe: (Service) Version is 1.6.1 Oct 9 09:47:33 raspberrypi weewx[31856] INFO user.MQTTSubscribe: (Service) Log level: 0 Oct 9 09:47:33 raspberrypi weewx[31856] INFO user.MQTTSubscribe: (Service) Log debug setting: 0 Oct 9 09:47:33 raspberrypi weewx[31856] INFO user.MQTTSubscribe: (Service) Log consol
[weewx-user] Re: Using MQTT Subscribe
Thanks, Rich. I'll try it when I get back. I'll be in our second home for a few days: going to the gun range and the clothing-optional resort (not at the same time!). On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 bell...@gmail.com wrote: > So, the [[[first/topic]]] are meant to be replaced with the actual topic. > So it would be something like this > ``` > [[Topics]] > [[[topic name that snowDepth is published on]]] > topic name that snowDepth is published on > name = snowDepth > [[[topic name that snowRate is published on]]] > topic name that snowRate is published on > name = snowRate > ``` > The duplication is an artifact of dealing with json and keyword payloads. > The ```use_topic_as_fieldname``` option can be used to make the config a > bit prettier. > ``` > [[Topics]] > use_topic_as_fieldname = true > [[[topic name that snowDepth is published on]]] > name = snowDepth > [[[topic name that snowRate is published on]]] > name = snowRate > ``` > Note, if snowDepth is actually published on the topic snowDepth, the > ```name``` option can be left off. > I don’t think that you want to set contains_total=true for snowDepth. This > is used when the field contains a total and it needs to be converted into > an increment for WeeWX. > > I’ll work on clarifying the wiki. > > With that said, it shouldn’t have broken WeeWX. If you are up for it, > before changing the config, setting debug=1, restarting WeeWX for a couple > of archive intervals and attaching the log would be appreciated . > > rich > > > > On Tuesday, 6 October 2020 at 13:28:34 UTC-4 timothye...@gmail.com wrote: > >> Attached is the extension material that I put into weewx.conf. But when I >> set enable = true, weewx stops archiving data. Is there an error in this >> configuration, or could subscribe be incompatible with another service? I'm >> using the Weatherflowudp driver with mqtt and GW1000 extensions. >> >> On Tuesday, October 6, 2020 at 9:17:07 AM UTC-6 Timothy Buchanan wrote: >> >>> Thanks, Rich, I should be able to edit weewx.conf based on the example >>> at the bottom of that page. >>> >>> I am using an ESP8266 board with an ultrasonic sensor and a temperature >>> sensor (to calibrate the speed of sound), and programming in the Arduino >>> IDE. I'll 3D print a case and mount it above my deck. The materials cost >>> about $15. >>> >>> I'd be happy to post the code here, under a new topic, once I get it >>> working. >>> >>> Timothy >>> >>> On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 storm...@gmail.com >>> wrote: >>> >>>> What type of sensor are you using for measuring snow depth? >>>> >>>> >>>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/76937438-5fe8-4c3d-a121-2557438a12b4n%40googlegroups.com.
[weewx-user] Re: Using MQTT Subscribe
Attached is the extension material that I put into weewx.conf. But when I set enable = true, weewx stops archiving data. Is there an error in this configuration, or could subscribe be incompatible with another service? I'm using the Weatherflowudp driver with mqtt and GW1000 extensions. On Tuesday, October 6, 2020 at 9:17:07 AM UTC-6 Timothy Buchanan wrote: > Thanks, Rich, I should be able to edit weewx.conf based on the example at > the bottom of that page. > > I am using an ESP8266 board with an ultrasonic sensor and a temperature > sensor (to calibrate the speed of sound), and programming in the Arduino > IDE. I'll 3D print a case and mount it above my deck. The materials cost > about $15. > > I'd be happy to post the code here, under a new topic, once I get it > working. > > Timothy > > On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 storm...@gmail.com wrote: > >> What type of sensor are you using for measuring snow depth? >> >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d867098c-1d57-40a3-af07-30afc8a676b6n%40googlegroups.com. # Options for extension 'MQTTSubscribe' [MQTTSubscribeService] # This section is for the MQTTSubscribe service. # Turn the service on and off. # Default is: true # Only used by the service. enable = false # The MQTT server. # Default is localhost. host = localhost # The port to connect to. # Default is 1883. port = 1883 # Maximum period in seconds allowed between communications with the broker. # Default is 60. keepalive = 60 # username for broker authentication. # Default is None. username = None # password for broker authentication. # Default is None. password = None # The binding, loop or archive. # Default is: loop # Only used by the service. binding = loop # The message handler to use [[message_callback]] # The format of the MQTT payload. # Currently support: individual, json, keyword # Must be specified. type = individual # The topics to subscribe to. [[topics]] # Units for MQTT payloads without unit value. # Valid values: US, METRIC, METRICWX # Default is: US unit_system = US # The first topic # MQTT Topic [[[first/topic]]] # MQTT name snowDepth # weewx name name = snowDepth ignore = false contains_total = True conversion_type = float units = inch # The second topic [[[second/topic]]] snowRate name = snowRate ignore = false contains_total = False conversion_type = float units = inch_per_hour # The third topic [[[third/topic]]] snowBatteryStatus name = snowBatteryStatus ignore = false contains_total = False conversion_type = float units = volt
[weewx-user] Re: Using MQTT Subscribe
Thanks, Rich, I should be able to edit weewx.conf based on the example at the bottom of that page. I am using an ESP8266 board with an ultrasonic sensor and a temperature sensor (to calibrate the speed of sound), and programming in the Arduino IDE. I'll 3D print a case and mount it above my deck. The materials cost about $15. I'd be happy to post the code here, under a new topic, once I get it working. Timothy On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 storm...@gmail.com wrote: > What type of sensor are you using for measuring snow depth? > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d1010c66-c10a-4a97-9499-79afd3afdb5an%40googlegroups.com.
Re: [weewx-user] Re: Using MQTT Subscribe
Thanks, changing the database was easy with that article. As to my other question, I'm guessing I need to put a Sensor Map in weewx.conf in the MQTTSubscribe section, something like snow/snowlevel = snow? On Monday, October 5, 2020 at 6:59:11 PM UTC-6 tke...@gmail.com wrote: > The schemas are used *only when creating a new database*. Upgrading to > v4.x will not change your old database. > > If you wish to switch, there is a Wiki article *Switching to the new > wview_extended schema > <https://github.com/weewx/weewx/wiki/Switching-to-the-new-wview_extended-schema>* > on > how to do it. > > On Mon, Oct 5, 2020 at 5:09 PM Timothy Buchanan > wrote: > >> I upgraded to 4.1.1 but I don't see these entries in the database. Do I >> have to install or change something to get the "extended" schema? >> >> On Monday, October 5, 2020 at 12:20:12 PM UTC-6 storm...@gmail.com wrote: >> >>> WeeWX Version 4.1.1 using the extended schema has entries for snow. >>> >>> >>> >>> >>> >>> On Monday, October 5, 2020 at 10:30:47 AM UTC-4, Timothy Buchanan wrote: >>>> >>>> I use the mqtt extension to publish to a mosquitto broker, and want to >>>> use MQTTSubscribe to receive topics posted by another device and put them >>>> into the weewx database. I installed MQTTSubscribe as an extension >>>> following the wiki, enabled it, and it didn't break anything (always >>>> good!). >>>> >>>> Next, I may need to extend the database, since there doesn't seem to be >>>> snowLevel entries, and to map the published topics to the database. where >>>> could I find information on these two subjects? Thanks. >>>> >>>> Timothy >>>> >>> -- >> 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/e4f7cdca-aec1-42f7-b232-5bdec8f90501n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/e4f7cdca-aec1-42f7-b232-5bdec8f90501n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d774c276-2929-447b-89be-42c186b08999n%40googlegroups.com.
[weewx-user] Re: Using MQTT Subscribe
I upgraded to 4.1.1 but I don't see these entries in the database. Do I have to install or change something to get the "extended" schema? On Monday, October 5, 2020 at 12:20:12 PM UTC-6 storm...@gmail.com wrote: > WeeWX Version 4.1.1 using the extended schema has entries for snow. > > > > > > On Monday, October 5, 2020 at 10:30:47 AM UTC-4, Timothy Buchanan wrote: >> >> I use the mqtt extension to publish to a mosquitto broker, and want to >> use MQTTSubscribe to receive topics posted by another device and put them >> into the weewx database. I installed MQTTSubscribe as an extension >> following the wiki, enabled it, and it didn't break anything (always good!). >> >> Next, I may need to extend the database, since there doesn't seem to be >> snowLevel entries, and to map the published topics to the database. where >> could I find information on these two subjects? Thanks. >> >> Timothy >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e4f7cdca-aec1-42f7-b232-5bdec8f90501n%40googlegroups.com.
[weewx-user] Using MQTT Subscribe
I use the mqtt extension to publish to a mosquitto broker, and want to use MQTTSubscribe to receive topics posted by another device and put them into the weewx database. I installed MQTTSubscribe as an extension following the wiki, enabled it, and it didn't break anything (always good!). Next, I may need to extend the database, since there doesn't seem to be snowLevel entries, and to map the published topics to the database. where could I find information on these two subjects? Thanks. Timothy -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/605841a8-6f48-4010-b0ec-aee6faecb9den%40googlegroups.com.
Re: [weewx-user] Issue with exfoliation weewx 4.1.1 and python3 - I think?
Thanks! Those changes fixed all. You can see my pi weather server at http://millennialhouse.ddns.net/wx/ On Thursday, September 3, 2020 at 4:16:01 PM UTC-6 jo...@johnkline.com wrote: > > what I'd like to know is what lines had to be changed in the templates > to make it work with python3? > > You can see exactly what I changed here: > > https://github.com/chaunceygardiner/weewx-exfoliation/commit/19ec9af514b2b32076713967911a9e5baffb6930 > > On Sep 3, 2020, at 2:01 PM, Timothy Buchanan > wrote: > > Thanks, that port does work, and forecast already worked. My skin is > modified from exfoliation, so what I'd like to know is what lines had to be > changed in the templates to make it work with python3? > > > > On Thursday, September 3, 2020 at 2:44:53 PM UTC-6 jo...@johnkline.com > wrote: > >> I did a quick port of exfoliation for someone who wanted to get it to >> work with WeeWX 4/Py3. >> >> You are welcome to try it: >> https://github.com/chaunceygardiner/weewx-exfoliation >> >> If you want it to work with the forecast plugin, I have that working with >> WeeWX4/Py3 at: >> https://github.com/chaunceygardiner/weewx-forecast >> >> >> On Sep 3, 2020, at 12:20 PM, Timothy Buchanan >> wrote: >> >> I have a similar problem with python3 and extension. The index and >> history pages are being generated. I made the first change listed above, >> but my index template doesn't have a show_pop. Here is the syslog extract: >> >> >> >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Generate failed with exception '' >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Ignoring template /etc/weewx/skins/exfoliation/index.html.tmpl >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Reason: '>' not supported between instances of 'NoneType' and 'int' >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Traceback (most recent call last): >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in >> generate >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> unicode_string = compiled_template.respond() >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File >> "cheetah__etc_weewx_skins_exfoliation_index_html_tmpl_1599160522_6806855_35363.py", >> >> line 1380, in respond >> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> TypeError: '>' not supported between instances of 'NoneType' and 'int' >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Generate failed with exception '' >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Ignoring template /etc/weewx/skins/exfoliation/forecast.html.tmpl >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Reason: '>' not supported between instances of 'NoneType' and 'int' >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> Traceback (most recent call last): >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in >> generate >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> unicode_string = compiled_template.respond() >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File "_etc_weewx_skins_exfoliation_forecast_html_tmpl.py", line >> 384, in respond >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line >> 1707, in _handleCheetahInclude >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> self._CHEETAH__cheetahIncludes[_includeID].respond(trans) >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> File "_etc_weewx_skins_exfoliation_forecast_table_inc.py", line >> 530, in respond >> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator: >> TypeError: '>' not supported between instances of 'NoneType' and 'int >> >> On Saturday, July 11, 2020 at 4:23:13 PM UTC-6 kb2...@kb2ear.net wrote: >> >>> I changed the first one and all my errors went away. I’m not sure I w
Re: [weewx-user] Issue with exfoliation weewx 4.1.1 and python3 - I think?
Thanks, that port does work, and forecast already worked. My skin is
modified from exfoliation, so what I'd like to know is what lines had to be
changed in the templates to make it work with python3?
On Thursday, September 3, 2020 at 2:44:53 PM UTC-6 jo...@johnkline.com
wrote:
> I did a quick port of exfoliation for someone who wanted to get it to work
> with WeeWX 4/Py3.
>
> You are welcome to try it:
> https://github.com/chaunceygardiner/weewx-exfoliation
>
> If you want it to work with the forecast plugin, I have that working with
> WeeWX4/Py3 at:
> https://github.com/chaunceygardiner/weewx-forecast
>
>
> On Sep 3, 2020, at 12:20 PM, Timothy Buchanan
> wrote:
>
> I have a similar problem with python3 and extension. The index and
> history pages are being generated. I made the first change listed above,
> but my index template doesn't have a show_pop. Here is the syslog extract:
>
>
>
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Generate failed with exception ''
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Ignoring template /etc/weewx/skins/exfoliation/index.html.tmpl
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Reason: '>' not supported between instances of 'NoneType' and 'int'
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Traceback (most recent call last):
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in
> generate
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> unicode_string = compiled_template.respond()
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File
> "cheetah__etc_weewx_skins_exfoliation_index_html_tmpl_1599160522_6806855_35363.py",
>
> line 1380, in respond
> Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> TypeError: '>' not supported between instances of 'NoneType' and 'int'
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Generate failed with exception ''
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Ignoring template /etc/weewx/skins/exfoliation/forecast.html.tmpl
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Reason: '>' not supported between instances of 'NoneType' and 'int'
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> Traceback (most recent call last):
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in
> generate
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> unicode_string = compiled_template.respond()
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File "_etc_weewx_skins_exfoliation_forecast_html_tmpl.py", line
> 384, in respond
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line
> 1707, in _handleCheetahInclude
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> self._CHEETAH__cheetahIncludes[_includeID].respond(trans)
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> File "_etc_weewx_skins_exfoliation_forecast_table_inc.py", line
> 530, in respond
> Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
> TypeError: '>' not supported between instances of 'NoneType' and 'int
>
> On Saturday, July 11, 2020 at 4:23:13 PM UTC-6 kb2...@kb2ear.net wrote:
>
>> I changed the first one and all my errors went away. I’m not sure I was
>> having the second part of the error.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Scott KB2EAR
>>
>> http://weather.kb2ear.net/exfoliation
>>
>>
>>
>>
>>
>> *From:* weewx...@googlegroups.com *On Behalf
>> Of *Tom Keffer
>> *Sent:* Saturday, July 11, 2020 6:07 PM
>> *To:* weewx-user
>> *Subject:* Re: [weewx-user] Issue with exfoliation weewx 4.1.1 and
>> python3 - I think?
>>
>>
>>
>> For the first error, in file index.html.tmpl, line 226, change this
>>
>>
>>
>> #if $varExists('trend') and $trend.windSpeed.raw is not None
>>
>> $get_windspeed_trend($trend.windSpeed.formatted)
>>
>> #end if
>>
>>
>>
>> to this
>>
&g
Re: [weewx-user] Issue with exfoliation weewx 4.1.1 and python3 - I think?
I have a similar problem with python3 and extension. The index and history
pages are being generated. I made the first change listed above, but my
index template doesn't have a show_pop. Here is the syslog extract:
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Generate failed with exception ''
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Ignoring template /etc/weewx/skins/exfoliation/index.html.tmpl
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Reason: '>' not supported between instances of 'NoneType' and 'int'
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Traceback (most recent call last):
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in generate
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
unicode_string = compiled_template.respond()
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File
"cheetah__etc_weewx_skins_exfoliation_index_html_tmpl_1599160522_6806855_35363.py",
line 1380, in respond
Sep 3 13:15:22 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
TypeError: '>' not supported between instances of 'NoneType' and 'int'
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Generate failed with exception ''
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Ignoring template /etc/weewx/skins/exfoliation/forecast.html.tmpl
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Reason: '>' not supported between instances of 'NoneType' and 'int'
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
Traceback (most recent call last):
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 322, in generate
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
unicode_string = compiled_template.respond()
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File "_etc_weewx_skins_exfoliation_forecast_html_tmpl.py", line 384, in
respond
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1707, in
_handleCheetahInclude
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
self._CHEETAH__cheetahIncludes[_includeID].respond(trans)
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
File "_etc_weewx_skins_exfoliation_forecast_table_inc.py", line 530, in
respond
Sep 3 13:15:23 raspberrypi weewx[8261] ERROR weewx.cheetahgenerator:
TypeError: '>' not supported between instances of 'NoneType' and 'int
On Saturday, July 11, 2020 at 4:23:13 PM UTC-6 kb2...@kb2ear.net wrote:
> I changed the first one and all my errors went away. I’m not sure I was
> having the second part of the error.
>
>
>
>
>
> Thanks,
>
> Scott KB2EAR
>
> http://weather.kb2ear.net/exfoliation
>
>
>
>
>
> *From:* weewx...@googlegroups.com *On Behalf
> Of *Tom Keffer
> *Sent:* Saturday, July 11, 2020 6:07 PM
> *To:* weewx-user
> *Subject:* Re: [weewx-user] Issue with exfoliation weewx 4.1.1 and
> python3 - I think?
>
>
>
> For the first error, in file index.html.tmpl, line 226, change this
>
>
>
> #if $varExists('trend') and $trend.windSpeed.raw is not None
>
> $get_windspeed_trend($trend.windSpeed.formatted)
>
> #end if
>
>
>
> to this
>
>
>
> #if $varExists('trend') and $trend.windSpeed.raw is not None
>
> $get_windspeed_trend($trend.windSpeed.raw)
>
> #end if
>
>
>
> For the second error, there are a number of candidates that could be
> causing this problem. I'd go with this one. Change this
>
>
>
> #if $show_pop
>
>
>
> #if $period.pop.raw > 0
>
> $period.pop.format('%.0f',' ')
>
> #end if
>
>
>
> #if $period.qpf.raw > 0
>
> $period.qpf.nolabel('%.2f',' ') src='icons/raindrop.png' />
>
> #end if
>
>
>
> #if $period.qsf.raw > 0
>
> $period.qsf.nolabel('%.2f',' ') src='icons/snowflake.png' />
>
> #end if
>
>
>
> #end if
>
>
>
> to this
>
>
>
> #if $show_pop
>
>
>
> #if $period.pop.raw is not None and $period.pop.raw > 0
>
> $period.pop.format('%.0f',' ')
>
> #end if
>
>
>
> #if $period.qpf.raw is not None and $period.qpf.raw > 0
>
> $period.qpf.nolabel('%.2f',' ') src='icons/raindrop.png' />
>
> #end if
>
>
>
> #if $period.qsf.raw is not None and $period.qsf.raw > 0
>
> $period.qsf.nolabel('%.2f',' ') src='icons/snowflake.png' />
>
> #end if
>
>
>
> #end if
>
>
>
> But I could be wrong on that.
>
>
>
> -tk
>
>
>
>
>
> On Thu, Jun 4, 2020 at 6:14 AM Mike Thompson
> wrote:
>
> Hi Fourm & Matt,
>
>
>
> I'm
Re: [weewx-user] weewx upgrade from python2 to python3
Thanks; that fixed the problem with Cheetah. I still have a problem with the skin I'm using (exfoliation), but that's for another thread. On Wednesday, September 2, 2020 at 5:12:04 PM UTC-6 tke...@gmail.com wrote: > You need Python 3 versions of all the prerequisites. To install them, > follow step 1 (and only step 1) from the setup.py instructions > <http://www.weewx.com/docs/setup.htm>. > > On Wed, Sep 2, 2020 at 2:34 PM Timothy Buchanan > wrote: > >> I tried this procedure, and with python3 I get an error that Cheetah is >> not found. Log extract: >> >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: Caught >> unrecoverable exception: >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: No >> module named 'Cheetah' >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> Traceback (most recent call last): >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/weewxd", line 148, in main >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> engine = weewx.engine.StdEngine(config_dict) >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/weewx/engine.py", line 75, in __init__ >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> self.loadServices(config_dict) >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/weewx/engine.py", line 138, in loadServices >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> obj = weeutil.weeutil.get_object(svc)(self,config_dict) >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/weeutil/weeutil.py", line 1093, in get_object >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> mod = __import__(module) >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/user/forecast.py", line 556, in >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> from weewx.cheetahgenerator import SearchList >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 66, in >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> import Cheetah.Filters >> Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: >> ModuleNotFoundError >> >> Weewx version is 4.1.1. Do I need to install a new version of Cheetah? If >> so, how? All is working under python2. Thanks. >> >> On Tuesday, September 1, 2020 at 3:01:03 PM UTC-6 bgra...@umw.edu wrote: >> >>> Thanks to everyone for the help. >>> Bob >>> >>> On Tuesday, September 1, 2020 at 2:50:51 PM UTC-4 wwwd...@gmail.com >>> wrote: >>> >>>> I just went through the same thing, as was mentioned above make sure >>>> all of your plugins have been updated to the latest version. I had a few >>>> plugins that I no longer run as they hadn't been upgraded and after a look >>>> at the code the work to upgrade them was more than I was willing to >>>> tackle. >>>> WeeWX-WD for example (although someone has a work-in-progress repo where >>>> it's being worked on, but doesn't have any releases yet -- I did an >>>> install >>>> from a GitHub clone and it seems to be working so far). >>>> >>>> At least for the two simple plugins I wrote I just had to change Queue >>>> to queue and replace urllib2 with urllib.request. >>>> >>>> On Tuesday, September 1, 2020 at 11:32:49 AM UTC-7 tke...@gmail.com >>>> wrote: >>>> >>>>> Same issue, except this time, it's cmon. Your version has not been >>>>> ported to Python 3. Fortunately, a newer version is available which has. >>>>> >>>>> On Tue, Sep 1, 2020 at 11:28 AM bgra...@umw.edu >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> Seeing the discussion of python3, I thought I would do the switch >>>>>> myself but ran into some errors. See below: >>>>>> >>>>>> +++ >>>>>> /var/log/weewx.log: >>>>>> Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Initializing weewx >>>>>
Re: [weewx-user] weewx upgrade from python2 to python3
I tried this procedure, and with python3 I get an error that Cheetah is not found. Log extract: Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: Caught unrecoverable exception: Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: No module named 'Cheetah' Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: Traceback (most recent call last): Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/weewxd", line 148, in main Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: engine = weewx.engine.StdEngine(config_dict) Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/weewx/engine.py", line 75, in __init__ Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: self.loadServices(config_dict) Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/weewx/engine.py", line 138, in loadServices Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: obj = weeutil.weeutil.get_object(svc)(self,config_dict) Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/weeutil/weeutil.py", line 1093, in get_object Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: mod = __import__(module) Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/user/forecast.py", line 556, in Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: from weewx.cheetahgenerator import SearchList Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: File "/usr/share/weewx/weewx/cheetahgenerator.py", line 66, in Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: import Cheetah.Filters Sep 2 15:28:18 raspberrypi weewx[1426] CRITICAL __main__: ModuleNotFoundError Weewx version is 4.1.1. Do I need to install a new version of Cheetah? If so, how? All is working under python2. Thanks. On Tuesday, September 1, 2020 at 3:01:03 PM UTC-6 bgra...@umw.edu wrote: > Thanks to everyone for the help. > Bob > > On Tuesday, September 1, 2020 at 2:50:51 PM UTC-4 wwwd...@gmail.com wrote: > >> I just went through the same thing, as was mentioned above make sure all >> of your plugins have been updated to the latest version. I had a few >> plugins that I no longer run as they hadn't been upgraded and after a look >> at the code the work to upgrade them was more than I was willing to tackle. >> WeeWX-WD for example (although someone has a work-in-progress repo where >> it's being worked on, but doesn't have any releases yet -- I did an install >> from a GitHub clone and it seems to be working so far). >> >> At least for the two simple plugins I wrote I just had to change Queue to >> queue and replace urllib2 with urllib.request. >> >> On Tuesday, September 1, 2020 at 11:32:49 AM UTC-7 tke...@gmail.com >> wrote: >> >>> Same issue, except this time, it's cmon. Your version has not been >>> ported to Python 3. Fortunately, a newer version is available which has. >>> >>> On Tue, Sep 1, 2020 at 11:28 AM bgra...@umw.edu wrote: >>> Hello, Seeing the discussion of python3, I thought I would do the switch myself but ran into some errors. See below: +++ /var/log/weewx.log: Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Initializing weewx version 4.1.1 Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Using Python 3.6.9 (default, Jul 17 2020, 12:50:27) #012[GCC 8.4.0] Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Platform Linux-4.15.0-115-generic-x86_64-with-Ubuntu-18.04-bionic Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Locale is 'en_US.UTF-8' Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Using configuration file /home/weewx/weewx.conf Sep 1 11:51:21 n4mrv weewx[3283] INFO __main__: Debug is 0 Sep 1 11:51:21 n4mrv weewx[3283] INFO weewx.engine: Loading station type Vantage (weewx.drivers.vantage) Sep 1 11:51:21 n4mrv weewx[3283] INFO weewx.engine: StdConvert target unit is 0x1 Sep 1 11:51:21 n4mrv weewx[3283] INFO weewx.wxservices: The following values will be calculated: pressure=prefer_hardware, barometer=prefer_hardware, altimeter=prefer_hardware, windchill=prefer_hardware, heatindex=prefer_hardware, dewpoint=prefer_hardware, inDewpoint=prefer_hardware, rainRate=prefer_hardware, maxSolarRad=prefer_hardware, cloudbase=prefer_hardware, humidex=prefer_hardware, appTemp=prefer_hardware, ET=prefer_hardware, windrun=prefer_hardware Sep 1 11:51:21 n4mrv weewx[3283] INFO weewx.wxservices: The following algorithms will be used for calculations: altimeter=aaASOS, maxSolarRad=RS Sep 1 11:51:21 n4mrv weewx[3283] CRITICAL __main__: Caught unrecoverable
Re: [weewx-user] Re: Forecast skin stopped working
Thanks; that worked. I did try an uninstall/reinstall, but used the (old) version pointed to in the wiki. Perhaps that link should be updated. On Sunday, August 30, 2020 at 12:59:31 PM UTC-6 jo...@johnkline.com wrote: > You are using a version of forecast that has not yet been fully ported to > WeeWX 4. > > You will have better luck here: > https://github.com/chaunceygardiner/weewx-forecast/releases > > On Aug 30, 2020, at 11:54 AM, Timothy Buchanan > wrote: > > > > > I've attached a syslog extract. I noticed this near the end of file: > > Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: got 38 > forecast records for WOODLAND PARK-TELLER CO 38.99N 105.05W Elev. 8922 ft > Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: saving 38 > forecast records > Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: forecast > failure: addRecord() got an unexpected keyword argument 'log_level > > Maybe this indicates the problem? > On Saturday, August 29, 2020 at 10:47:28 AM UTC-6 andrew.s...@gmail.com > wrote: > >> posting your log may help identify any problems >> >> >> On Saturday, 29 August 2020 16:53:43 UTC+3, Timothy Buchanan wrote: >>> >>> I I've been using Forecast within a modified exfoliation skin with no >>> problems until it stopped fetching the forecasts. I use NWS and Open >>> Weather and these dwindled from a seven day to five, three, one, then none. >>> Running the Forecast skin gives the same non-result. Where would I look >>> for the problem? I tried an uninstall/reinstall to no avail. Thanks for >>> help. >>> >>> Timothy >>> >> -- > 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/ea6fd6a9-7e07-4f5f-acfe-5244563cac07n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/ea6fd6a9-7e07-4f5f-acfe-5244563cac07n%40googlegroups.com?utm_medium=email_source=footer> > . > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c1c98bab-2fb1-4208-b14f-4e5621560d0fn%40googlegroups.com.
[weewx-user] Re: Forecast skin stopped working
I've attached a syslog extract. I noticed this near the end of file:
Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: got 38
forecast records for WOODLAND PARK-TELLER CO 38.99N 105.05W Elev. 8922 ft
Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: saving 38
forecast records
Aug 30 12:40:25 raspberrypi weewxd: forecast: NWSThread: NWS: forecast
failure: addRecord() got an unexpected keyword argument 'log_level
Maybe this indicates the problem?
On Saturday, August 29, 2020 at 10:47:28 AM UTC-6 andrew.s...@gmail.com
wrote:
> posting your log may help identify any problems
>
>
> On Saturday, 29 August 2020 16:53:43 UTC+3, Timothy Buchanan wrote:
>>
>> I I've been using Forecast within a modified exfoliation skin with no
>> problems until it stopped fetching the forecasts. I use NWS and Open
>> Weather and these dwindled from a seven day to five, three, one, then none.
>> Running the Forecast skin gives the same non-result. Where would I look
>> for the problem? I tried an uninstall/reinstall to no avail. Thanks for
>> help.
>>
>> Timothy
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/ea6fd6a9-7e07-4f5f-acfe-5244563cac07n%40googlegroups.com.
Aug 30 12:32:38 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Aug 30 12:32:45 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Aug 30 12:32:45 raspberrypi weewx[1252] INFO __main__: Initializing weewx
version 4.1.1
Aug 30 12:32:45 raspberrypi weewx[1252] INFO __main__: Using Python 2.7.16
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Aug 30 12:32:45 raspberrypi weewx[1252] INFO __main__: Platform
Linux-5.4.51-v7l+-armv7l-with-debian-10.4
Aug 30 12:32:45 raspberrypi weewx[1252] INFO __main__: Locale is 'en_US.UTF-8'
Aug 30 12:32:45 raspberrypi weewx[1252] INFO __main__: PID file is
/var/run/weewx.pid
Aug 30 12:32:45 raspberrypi weewx[1240]: Starting weewx weather system: weewx.
Aug 30 12:32:45 raspberrypi systemd[1]: Started LSB: weewx weather system.
Aug 30 12:32:45 raspberrypi weewx[1257] INFO __main__: Using configuration file
/etc/weewx/weewx.conf
Aug 30 12:32:45 raspberrypi weewx[1257] INFO __main__: Debug is 0
Aug 30 12:32:45 raspberrypi weewx[1257] INFO weewx.engine: Loading station type
WeatherFlowUDP (user.weatherflowudp)
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: driver version
is 1.03
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: sensor map is
{u'outTemp': u'air_temperature.AR-00017660.obs_air', u'outHumidity':
u'relative_humidity.AR-00017660.obs_air', u'pressure':
u'station_pressure.AR-00017660.obs_air', u'lightning_strikes':
u'lightning_strike_count.AR-00017660.obs_air', u'avg_distance':
u'lightning_strike_avg_distance.AR-00017660.obs_air', u'outTempBatteryStatus':
u'battery.AR-00017660.obs_air', u'windSpeed':
u'wind_speed.SK-00017445.rapid_wind', u'windDir':
u'wind_direction.SK-00017445.rapid_wind', u'windGust':
u'wind_gust.SK-00017445.obs_sky', u'lux': u'illuminance.SK-00017445.obs_sky',
u'UV': u'uv.SK-00017445.obs_sky', u'rain':
u'rain_accumulated.SK-00017445.obs_sky', u'windBatteryStatus':
u'battery.SK-00017445.obs_sky', u'radiation':
u'solar_radiation.SK-00017445.obs_sky', u'lightningYYY':
u'distance.AR-00017660.evt_strike', u'lightningZZZ':
u'energy.AR-00017660.evt_strike'}
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: *** Sensor
names per packet type
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: packet
rapid_wind: ('time_epoch', 'wind_speed', 'wind_direction')
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_sky:
('time_epoch', 'illuminance', 'uv', 'rain_accumulated', 'wind_lull',
'wind_avg', 'wind_gust', 'wind_direction', 'battery', 'report_interval',
'solar_radiation', 'local_day_rain_accumulation', 'precipitation_type',
'wind_sample_interval')
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_air:
('time_epoch', 'station_pressure', 'air_temperature', 'relative_humidity',
'lightning_strike_count', 'lightning_strike_avg_distance', 'battery',
'report_interval')
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: packet
evt_precip: time_epoch
Aug 30 12:32:45 raspberrypi weewxd: weatherflowudp: MainThread: packet
evt_strike: ('time_epoch', 'distance', 'energy')
Aug 30 12:32:47 raspberrypi weewx[1257] INFO gw1000: user.gw1000: GW1000 was
found at 192.168.1.6:45000
Aug 30 12:32:47 raspberrypi weewx[1257] INFO gw1000: user.gw1000: field map is
{'dateTime': 'datetime', 'extraHumid1': 'humid1', 'extraHumid2': 'humid2',
'extraTemp1': 'temp1', 'extraTemp2': 'temp2',
[weewx-user] Forecast skin stopped working
I I've been using Forecast within a modified exfoliation skin with no problems until it stopped fetching the forecasts. I use NWS and Open Weather and these dwindled from a seven day to five, three, one, then none. Running the Forecast skin gives the same non-result. Where would I look for the problem? I tried an uninstall/reinstall to no avail. Thanks for help. Timothy -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ff4a887a-3e8e-448d-9f1a-fe4e34ffdaecn%40googlegroups.com.
Re: [weewx-user] GW1000 output and database
It is working fully now. Thanks, guys, for your efforts and patience. On Tuesday, August 25, 2020 at 1:27:19 AM UTC-6 gjr80 wrote: > Actually, looking at the code I can see that timestamps of the GW1000 data > are handled differently when operated as a driver and as a service. In this > case adding dateTime = datetime to [[field_map]] will get things > operating as expected. > > I need to revisit the handling of GW1000 data timestamps, the need for > dateTime > = datetime may or may not be the final solution. Either way the final > version will be backwards compatible with a dateTime = datetime entry in > the field map.This issue has also highlighted the need for some better > debug output around the processing of loop packets. > > Gary > On Tuesday, 25 August 2020 at 16:34:25 UTC+10 graha...@gmail.com wrote: > >> add ‘dateTime = datetime’ back to field_map. >> worth a go while gary works on it >> >> On 25 Aug 2020, at 8:37 am, Timothy Buchanan >> wrote: >> >> How would I add dateTime to the field_map? >> >> On Monday, August 24, 2020 at 9:59:17 AM UTC-6 graha...@gmail.com wrote: >> >>> try adding ‘dateTime’ to the field_map. i think augmentations are >>> skipped (gw1000 fields are not added) because on its absence the service >>> assumes the offered data is infinitely old >>> >>> On 25 Aug 2020, at 12:47 am, Graham Eddy wrote: >>> >>> it will be interesting to see what gary concludes. >>> it looks to me like the fields are correctly identified and mapped (i >>> presume; the data is there but i don't see the mapped result) but not >>> inserted into packet by augmentation. one reason for not inserting the data >>> would be if it is stale - do the timestamps of the weatherflowudp driver >>> (datetime in packet) line up with the gw1000 service (datetime in >>> mapped_data) within age toleration? >>> >>> On 24 Aug 2020, at 11:48 pm, Timothy Buchanan >>> wrote: >>> >>> field_map used with debug 3. >>> >>> On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote: >>> >>>> Thanks, from the log it looks like the GW1000 service thread has >>>> silently died (which it shouldn't, it should die loudly if it dies!). >>>> Let's >>>> step the debug level up, leaving everything else as it is edit >>>> weewx.conf and set debug = 3, save weewx.conf and restart WeeWX. Let >>>> WeeWX run for about five minutes and again take a log extract from when >>>> you >>>> just started WeeWX. Post the log here. >>>> >>>> Gary >>>> >>>> On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com >>>> wrote: >>>> >>>>> debug=2 GW options so (pasted): >>>>> >>>>> # Options for extension 'GW1000' >>>>> [GW1000] >>>>> driver = user.gw1000 >>>>> [[field_map]] >>>>> extraTemp2 = intemp >>>>> extraHumid2 = inhumid >>>>> extraTemp1 = temp1 >>>>> extraHumid1 = humid1 >>>>> soilMoist1 = soilmoist1 >>>>> >>>> >>> >>> >> -- >> 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/fb279140-dd76-4767-92b8-1cdb780a2e30n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/fb279140-dd76-4767-92b8-1cdb780a2e30n%40googlegroups.com?utm_medium=email_source=footer> >> . >> >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/3d7665f3-9743-4eeb-9c8a-91d543702826n%40googlegroups.com.
Re: [weewx-user] GW1000 output and database
How would I add dateTime to the field_map? On Monday, August 24, 2020 at 9:59:17 AM UTC-6 graha...@gmail.com wrote: > try adding ‘dateTime’ to the field_map. i think augmentations are skipped > (gw1000 fields are not added) because on its absence the service assumes > the offered data is infinitely old > > On 25 Aug 2020, at 12:47 am, Graham Eddy wrote: > > it will be interesting to see what gary concludes. > it looks to me like the fields are correctly identified and mapped (i > presume; the data is there but i don't see the mapped result) but not > inserted into packet by augmentation. one reason for not inserting the data > would be if it is stale - do the timestamps of the weatherflowudp driver > (datetime in packet) line up with the gw1000 service (datetime in > mapped_data) within age toleration? > > On 24 Aug 2020, at 11:48 pm, Timothy Buchanan > wrote: > > field_map used with debug 3. > > On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote: > >> Thanks, from the log it looks like the GW1000 service thread has silently >> died (which it shouldn't, it should die loudly if it dies!). Let's step the >> debug level up, leaving everything else as it is edit weewx.conf and set >> debug >> = 3, save weewx.conf and restart WeeWX. Let WeeWX run for about five >> minutes and again take a log extract from when you just started WeeWX. Post >> the log here. >> >> Gary >> >> On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com wrote: >> >>> debug=2 GW options so (pasted): >>> >>> # Options for extension 'GW1000' >>> [GW1000] >>> driver = user.gw1000 >>> [[field_map]] >>> extraTemp2 = intemp >>> extraHumid2 = inhumid >>> extraTemp1 = temp1 >>> extraHumid1 = humid1 >>> soilMoist1 = soilmoist1 >>> >> > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/fb279140-dd76-4767-92b8-1cdb780a2e30n%40googlegroups.com.
Re: [weewx-user] Re: GW1000 output and database
field_map used with debug 3. On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote: > Thanks, from the log it looks like the GW1000 service thread has silently > died (which it shouldn't, it should die loudly if it dies!). Let's step the > debug level up, leaving everything else as it is edit weewx.conf and set > debug > = 3, save weewx.conf and restart WeeWX. Let WeeWX run for about five > minutes and again take a log extract from when you just started WeeWX. Post > the log here. > > Gary > > On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com wrote: > >> debug=2 GW options so (pasted): >> >> # Options for extension 'GW1000' >> [GW1000] >> driver = user.gw1000 >> [[field_map]] >> extraTemp2 = intemp >> extraHumid2 = inhumid >> extraTemp1 = temp1 >> extraHumid1 = humid1 >> soilMoist1 = soilmoist1 >> >> Syslog extract and debug.txt attached. Output from this is null. Thanks >> again. >> >> >> >> On Sunday, August 23, 2020 at 3:11:24 PM UTC-6 gjr80 wrote: >> >>> Please don’t use [[field map]], it is ignored by the GW1000 >>> driver/service and will result in the default field map being used which >>> will map intemp to inTemp; it definitely will not map intemp to extraTemp2. >>> Plus we are left trying to work out if you made a typo or not. >>> >>> So we know the field map is being read and used (when [[field_map]] is >>> used) and the GW1000 is emitting intemp and inhumidity. Now we need to look >>> closer at how the data is processed through the GW1000 service. Can you >>> please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza >>> has [[field_map]] and that it is set to: >>> >>> [[field_map]] >>> extraTemp2 = intemp >>> extraHumid2 = inhumid >>> extraTemp1 = temp1 >>> extraHumid1 = humid1 >>> soilMoist1 = soilmoist1 >>> >>> Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes >>> then take a log extract from when WeeWX was restarted through until 10 >>> minutes elapsed and post the extract here. >>> >>> Can you also run wee_debug >>> <http://weewx.com/docs/utilities.htm#wee_debug_utility> and post the >>> wee_debug output, do check the wee_debug out for sensitive info such as >>> usernames, passwords and api keys etc, wee_debug should obfuscate such >>> entries but it is not perfect. >>> >>> Gary >>> On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com >>> wrote: >>> >>>> With bme280wx uninstalled and GW1000 set to [[field_map]], I get all >>>> nulls in the database. >>>> With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW >>>> values, but intemp and inhumid are sent to inTemp and inHumidity. >>>> I have switched back and forth repeatedly and this is what I get. >>>> With bme280wx installed, I get values from the bme280, but not from >>>> GW1000, no matter what settings I use. So it seems that bme280wx and >>>> GW1000 >>>> are incompatible. But maybe someone who is running a bme280 and GW1000 >>>> successfully will chime in here. >>>> >>>> Timothy >>>> >>>> On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com >>>> wrote: >>>> >>>>> this is still incorrect. it should be [[field_map]] ← note the >>>>> underscore >>>>> >>>>> On 24 Aug 2020, at 1:22 am, Timothy Buchanan >>>>> wrote: >>>>> >>>>> This morning, I deleted the other service and restarted weewx. GW1000 >>>>> not reports intemp and inhumid, but mapped to inTemp and inHumidity. Here >>>>> is the field_map: >>>>> >>>>> [[field map]] >>>>> extraTemp2 = intemp >>>>> extraHumid2 = inhumid >>>>> extraTemp1 = temp1 >>>>> extraHumid1 = humid1 >>>>> soilMoist1 = soilmoist1 >>>>> >>>>> >>>>> -- 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. To view this discussion on the web visit https://groups.google.com/
Re: [weewx-user] Re: GW1000 output and database
debug=2 GW options so (pasted): # Options for extension 'GW1000' [GW1000] driver = user.gw1000 [[field_map]] extraTemp2 = intemp extraHumid2 = inhumid extraTemp1 = temp1 extraHumid1 = humid1 soilMoist1 = soilmoist1 Syslog extract and debug.txt attached. Output from this is null. Thanks again. On Sunday, August 23, 2020 at 3:11:24 PM UTC-6 gjr80 wrote: > Please don’t use [[field map]], it is ignored by the GW1000 driver/service > and will result in the default field map being used which will map intemp > to inTemp; it definitely will not map intemp to extraTemp2. Plus we are > left trying to work out if you made a typo or not. > > So we know the field map is being read and used (when [[field_map]] is > used) and the GW1000 is emitting intemp and inhumidity. Now we need to look > closer at how the data is processed through the GW1000 service. Can you > please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza > has [[field_map]] and that it is set to: > > [[field_map]] > extraTemp2 = intemp > extraHumid2 = inhumid > extraTemp1 = temp1 > extraHumid1 = humid1 > soilMoist1 = soilmoist1 > > Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes then > take a log extract from when WeeWX was restarted through until 10 minutes > elapsed and post the extract here. > > Can you also run wee_debug > <http://weewx.com/docs/utilities.htm#wee_debug_utility> and post the > wee_debug output, do check the wee_debug out for sensitive info such as > usernames, passwords and api keys etc, wee_debug should obfuscate such > entries but it is not perfect. > > Gary > On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com wrote: > >> With bme280wx uninstalled and GW1000 set to [[field_map]], I get all >> nulls in the database. >> With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW >> values, but intemp and inhumid are sent to inTemp and inHumidity. >> I have switched back and forth repeatedly and this is what I get. >> With bme280wx installed, I get values from the bme280, but not from >> GW1000, no matter what settings I use. So it seems that bme280wx and GW1000 >> are incompatible. But maybe someone who is running a bme280 and GW1000 >> successfully will chime in here. >> >> Timothy >> >> On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote: >> >>> this is still incorrect. it should be [[field_map]] ← note the underscore >>> >>> On 24 Aug 2020, at 1:22 am, Timothy Buchanan >>> wrote: >>> >>> This morning, I deleted the other service and restarted weewx. GW1000 >>> not reports intemp and inhumid, but mapped to inTemp and inHumidity. Here >>> is the field_map: >>> >>> [[field map]] >>> extraTemp2 = intemp >>> extraHumid2 = inhumid >>> extraTemp1 = temp1 >>> extraHumid1 = humid1 >>> soilMoist1 = soilmoist1 >>> >>> >>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ef8df6d2-25f7-4764-82eb-003a04c0ed70n%40googlegroups.com. LOOP: 2020-08-22 08:10:35 MDT (1598105435) altimeter: 30.429894128, dateTime: 1598105435, extraHumid1: 37, extraTemp1: 63.86, inDewpoint: 42.2044328587, inHumidity: 32, inTemp: 73.94, lux: 20105, pressure: 22.2095035988, radiation: 167, rain: 0.0, rainRate: 0, relbarometer: 752.1, soilMoist1: 28, usUnits: 1, UV: 1.78, wh31_ch1_batt: 0, wh51_ch1_batt: 0, windBatteryStatus: 3.275, windGust: 5.90552648912 LOOP: 2020-08-22 08:10:37 MDT (1598105437) dateTime: 1598105437, rainRate: 0, usUnits: 1, windDir: 273, windSpeed: 3.31067394087 LOOP: 2020-08-22 08:10:37 MDT (1598105437) altimeter: 30.2965008953, avg_distance: 0, barometer: 29.9037865166, dateTime: 1598105437, dewpoint: 35.9378281214, heatindex: 66.74, lightning_strikes: 0, outHumidity: 32, outTemp: 66.74, outTempBatteryStatus: 2.944, pressure: 22.1061486425, rainRate: 0, usUnits: 1 LOOP: 2020-08-22 08:10:43 MDT (1598105443) dateTime: 1598105443, rainRate: 0, usUnits: 1, windDir: 264, windSpeed: 4.80942498167 LOOP: 2020-08-22 08:10:46 MDT (1598105446) dateTime: 1598105446, rainRate: 0, usUnits: 1, windDir: 241, windSpeed: 5.59235462985 LOOP: 2020-08-22 08:10:49 MDT (1598105449) dateTime: 1598105449, rainRate: 0, usUnits: 1, windDir: 273, windSpeed: 4.29492835572 LOOP: 2020-08-22 08:10:
Re: [weewx-user] Re: GW1000 output and database
With bme280wx uninstalled and GW1000 set to [[field_map]], I get all nulls in the database. With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW values, but intemp and inhumid are sent to inTemp and inHumidity. I have switched back and forth repeatedly and this is what I get. With bme280wx installed, I get values from the bme280, but not from GW1000, no matter what settings I use. So it seems that bme280wx and GW1000 are incompatible. But maybe someone who is running a bme280 and GW1000 successfully will chime in here. Timothy On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote: > this is still incorrect. it should be [[field_map]] ← note the underscore > > On 24 Aug 2020, at 1:22 am, Timothy Buchanan > wrote: > > This morning, I deleted the other service and restarted weewx. GW1000 not > reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is > the field_map: > > [[field map]] > extraTemp2 = intemp > extraHumid2 = inhumid > extraTemp1 = temp1 > extraHumid1 = humid1 > soilMoist1 = soilmoist1 > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0d220098-ae11-4c9c-9c84-66ab342ce598n%40googlegroups.com.
Re: [weewx-user] Re: GW1000 output and database
Here is live data:
GW1000 live sensor data: absbarometer: 753.4, datetime: 1598189179, humid1:
42, inhumid: 30, intemp: 21.7,
relbarometer: 753.4, soilmoist1: 26, temp1: 12.8, wh31_ch1_batt: 0,
wh51_ch1_batt: 0
This morning, I deleted the other service and restarted weewx. GW1000 not
reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is
the field_map:
[[field map]]
extraTemp2 = intemp
extraHumid2 = inhumid
extraTemp1 = temp1
extraHumid1 = humid1
soilMoist1 = soilmoist1
GW1000 intemp is mapped to extraTemp2, but is reported in the database as
inTemp, as if it is hard coded to do so.
Timothy
On Saturday, August 22, 2020 at 8:39:59 PM UTC-6 gjr80 wrote:
> The GW1000 data is being picked up every 60 seconds as it should but it is
> sans extraHumid2/extraTemp2. Time to look a little closer at what the
> GW1000 is picking up. Can you run the GW1000 driver directly with the
> --live-data command line option. For a setup.py install something like:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data
>
> or for a package install:
>
> $ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --live-data
>
> This will show us what data is available for use from the GW1000 and its
> connected sensors.
>
> Gary
> On Sunday, 23 August 2020 at 00:29:36 UTC+10 timothye...@gmail.com wrote:
>
>> Here is the output from one archive period; the REC loop is near the end.
>>
>> Timothy
>>
>> On Friday, August 21, 2020 at 11:51:41 PM UTC-6 gjr80 wrote:
>>
>>> Actually, now that we have the GW1000 field mapping set I suspect the
>>> answer may be in the loop packets. Tim has three sources contributing to
>>> loop packets, and on top of that I believe the Weatherflow driver emits
>>> partial packets which further complicates the process. that being said it
>>> should be possible to have all three work co-operatively, perhaps with some
>>> judicious config settings. As Graham said you need to run WeeWX directly
>>> <http://weewx.com/docs/usersguide.htm#Running_directly>, once it is
>>> running directly let it run for at least a full archive interval and then
>>> post the entire console output making sure you include at least one REC:
>>> line.
>>>
>>> Gary
>>>
>>>
>>> On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>>>
>>>> when you run weewx in foreground (not as daemon) so you can see the
>>>> weewx records, looking at the REC records (not LOOP records), what are the
>>>> fields being offered to archive service? then looking in weewx db, which
>>>> of
>>>> these fields are actally being populated in db?
>>>>
>>> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan
>>>> wrote:
>>>>
>>>> I think you're being helpful, not harping, and I appreciate it. I just
>>>> restarted weewx with [[field_map]] and found the following line in syslog:
>>>>
>>>> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000:
>>>> field map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>>>> 'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1':
>>>> 'soilmoist1'}
>>>>
>>>> so yes, it is mapping correctly but something is preventing these
>>>> values from being placed in the database, where they are all null.
>>>> Incidentally, if I use [[field_map_extension]] it is ignored and I get the
>>>> latter three values as before. So what could be keeping the mapped GW1000
>>>> service from the database?
>>>>
>>>> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
>>>>
>>>>> Sorry if you think I am harping on the [[field_map]] issue but I need
>>>>> to understand if we are trying to track down a field map issue or
>>>>> something
>>>>> else. Is the log extract you just posted with [[field map]] or
>>>>> [[field_map]]? because again it shows the setting was ignored.
>>>>>
>>>>> The reason that [[field map]] partially works is that it is completely
>>>>> ignored and the default map used, this results in GW1000 fields intemp
>>>>> and
>>>>> in humid being discarded because their mapped locations (WeeWX fields
>>>>> inTemp and inHumidity) are already populated. The GW1000 driver is coded
>>>>> to
>>>>> use two field map type stanzas; [[field_map]] and
>>>>> [[field_map_extension
Re: [weewx-user] Re: GW1000 output and database
Here is the output from one archive period; the REC loop is near the end.
Timothy
On Friday, August 21, 2020 at 11:51:41 PM UTC-6 gjr80 wrote:
> Actually, now that we have the GW1000 field mapping set I suspect the
> answer may be in the loop packets. Tim has three sources contributing to
> loop packets, and on top of that I believe the Weatherflow driver emits
> partial packets which further complicates the process. that being said it
> should be possible to have all three work co-operatively, perhaps with some
> judicious config settings. As Graham said you need to run WeeWX directly
> <http://weewx.com/docs/usersguide.htm#Running_directly>, once it is
> running directly let it run for at least a full archive interval and then
> post the entire console output making sure you include at least one REC:
> line.
>
> Gary
>
>
> On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>
>> when you run weewx in foreground (not as daemon) so you can see the weewx
>> records, looking at the REC records (not LOOP records), what are the fields
>> being offered to archive service? then looking in weewx db, which of these
>> fields are actally being populated in db?
>>
> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan
>> wrote:
>>
>> I think you're being helpful, not harping, and I appreciate it. I just
>> restarted weewx with [[field_map]] and found the following line in syslog:
>>
>> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: field
>> map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>> 'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1':
>> 'soilmoist1'}
>>
>> so yes, it is mapping correctly but something is preventing these values
>> from being placed in the database, where they are all null. Incidentally,
>> if I use [[field_map_extension]] it is ignored and I get the latter three
>> values as before. So what could be keeping the mapped GW1000 service from
>> the database?
>>
>> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
>>
>>> Sorry if you think I am harping on the [[field_map]] issue but I need to
>>> understand if we are trying to track down a field map issue or something
>>> else. Is the log extract you just posted with [[field map]] or
>>> [[field_map]]? because again it shows the setting was ignored.
>>>
>>> The reason that [[field map]] partially works is that it is completely
>>> ignored and the default map used, this results in GW1000 fields intemp and
>>> in humid being discarded because their mapped locations (WeeWX fields
>>> inTemp and inHumidity) are already populated. The GW1000 driver is coded to
>>> use two field map type stanzas; [[field_map]] and [[field_map_extensions]].
>>> As far as the field map is concerned anything else is ignored.
>>>
>>> Gary
>>>
>>> On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com
>>> wrote:
>>>
>>>> Yes, the GW1000 disconnected and I moved it close to the router for
>>>> testing, where I can see it. the router reserves an ip for it. I decided
>>>> to
>>>> start over. I uninstalled the extension, went back to an earlier
>>>> weewx.conf
>>>> then reinstalled the extension. I modified weewx.conf as shown in the
>>>> github page, and placed this in weewx.conf:
>>>>
>>>> # Options for extension 'GW1000'
>>>> [GW1000]
>>>> driver = user.gw1000
>>>> [[field map]]
>>>> extraTemp2 = intemp
>>>> extraHumid2 = inhumid
>>>> extraTemp1 = temp1
>>>> extraHumid1 = humid1
>>>> soilMoist1 = soilmoist1
>>>>
>>>> I've attached a syslog extract. I tried using [[field_map]], and that
>>>> made all values null. Using [[field map]] gives the last three values.
>>>> Maybe you could post a working GW Options field, and I will paste that
>>>> into
>>>> my weewx.conf and see what happens.
>>>>
>>>> On Thursday, August 20, 2020 at 8:37:57 PM UTC-6 gjr80 wrote:
>>>>
>>>>> The highlighted line tells me the default field map is being used and
>>>>> not [[field_map]]:
>>>>>
>>>>> Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading
>>>>> service user.gw1000.Gw1000Service
>>>>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000:
>>>>> GW1000 was found at 192.168.1.6:45000
>&g
[weewx-user] Re: GW1000 output and database
ilmoist12', >>> 'soilMoist13': 'soilmoist13', 'soilMoist14': 'soilmoist14', >>> 'soilMoist15': 'soilmoist15', 'soilMoist16': 'soilmoist16', 'soilTemp1': >>> 'soiltemp1', 'soilTemp2': 'soiltemp2', 'soilTemp3': 'soiltemp3', >>> 'soilTemp4': 'soiltemp4', 'soilTemp5': 'soiltemp5', 'soilTemp6': >>> 'soiltemp6', 'soilTemp7': 'soiltemp7', 'soilTemp8': 'soiltemp8', >>> 'soilTemp9': 'soiltemp9', 'soilTemp10': 'soiltemp10', 'soilTemp11': >>> 'soiltemp11', 'soilTemp12': 'soiltemp12', 'soilTemp13': 'soiltemp13', >>> 'soilTemp14': 'soiltemp14', 'soilTemp15': 'soiltemp15', 'soilTemp16': >>> 'soiltemp16', 'stormRain': 'rainevent', 'totalRain': 'raintotals', >>> 'uvradiation': 'uv', 'weekRain': 'rainweek', 'wh25_batt': 'wh25_batt', >>> 'wh26_batt': 'wh26_batt', 'wh31_ch1_batt': 'wh31_ch1_batt', >>> 'wh31_ch2_batt': 'wh31_ch2_batt', 'wh31_ch3_batt': 'wh31_ch3_batt', >>> 'wh31_ch4_batt': 'wh31_ch4_batt', 'wh31_ch5_batt': 'wh31_ch5_batt', >>> 'wh31_ch6_batt': 'wh31_ch6_batt', 'wh31_ch7_batt': 'wh31_ch7_batt', >>> 'wh31_ch8_batt': 'wh31_ch8_batt', 'wh40_batt': 'wh40_batt', >>> 'wh41_ch1_batt': 'wh41_ch1_batt', 'wh41_ch2_batt': 'wh41_ch2_batt', >>> 'wh41_ch3_batt': 'wh41_ch3_batt', 'wh41_ch4_batt': 'wh41_ch4_batt', >>> 'wh51_ch1_batt': 'wh51_ch1_batt', 'wh51_ch2_batt': 'wh51_ch2_batt', >>> 'wh51_ch3_batt': 'wh51_ch3_batt', 'wh51_ch4_batt': 'wh51_ch4_batt', >>> 'wh51_ch5_batt': 'wh51_ch5_batt', 'wh51_ch6_batt': 'wh51_ch6_batt', >>> 'wh51_ch7_batt': 'wh51_ch7_batt', 'wh51_ch8_batt': 'wh51_ch8_batt', >>> 'wh51_ch9_batt': 'wh51_ch9_batt', 'wh51_ch10_batt': 'wh51_ch10_batt', >>> 'wh51_ch11_batt': 'wh51_ch11_batt', 'wh51_ch12_batt': 'wh51_ch12_batt', >>> 'wh51_ch13_batt': 'wh51_ch13_batt', 'wh51_ch14_batt': 'wh51_ch14_batt', >>> 'wh51_ch15_batt': 'wh51_ch15_batt', 'wh51_ch16_batt': 'wh51_ch16_batt', >>> 'wh55_ch1_batt': 'wh55_ch1_batt', 'wh55_ch2_batt': 'wh55_ch2_batt', >>> 'wh55_ch3_batt': 'wh55_ch3_batt', 'wh55_ch4_batt': 'wh55_ch4_batt', >>> 'wh57_batt': 'wh57_batt', 'wh65_batt': 'wh65_batt', 'wh68_batt': >>> 'wh68_batt', 'windDir': 'winddir', 'windGust': 'gustspeed', 'windSpeed': >>> 'windspeed', 'windchill': 'windchill', 'ws80_batt': 'ws80_batt', >>> 'yearRain': 'rainyear'} >>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: >>> version is 0.1.0b11 >>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: >>> GW1000 IP address not specified, attempting to discover GW1000... >>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: >>> GW1000 address is 192.168.1.6:45000 >>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: poll >>> interval is 60 seconds >>> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: max >>> tries is 3, retry wait time is 10 seconds >>> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: >>> broadcast address 255.255.255.255:46000, socket timeout is 2 seconds >>> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: max >>> age of API data to be used is 60 seconds >>> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG weewx.engine: Finished >>> loading service user.gw1000.Gw1000Service >>> >>> What was your [GW1000] stanza when this was log was taken, if you did >>> not have [[field_map]] then we need to see the log extract with >>> [[field_map]]. >>> >>> This also tells me that whilst the GW1000 was found twice at startup >>> contact was subsequently lost with the GW1000 and it looks like contact was >>> not re-established: >>> >>> Aug 20 20:02:58 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: >>> Failed attempt 3 to send command 'CMD_GW1000_LIVEDATA': timed out >>> Aug 20 20:02:58 raspberrypi weewx[31556] ERROR gw1000: user.gw1000: >>> Failed to send command 'CMD_GW1000_LIVEDATA' after 3 attempts >>> Aug 20 20:02:58 raspberrypi weewx[31556] INFO gw1000: user.gw1000: >>> Attempting to re-discover GW1000... >>> >>> Would certainly explain the lack of GW1000 data. Have you noticed these >>> type of entries before? Is your GW1000 being allocated a fixed/static IP? >>> >>> Gary >>> >>> >>> On Friday, 21 August 2020 12:20:03 UTC+10, Timothy Buchanan wrote: >>>> >>>> [[field_map]] makes all values null, including the ones that worked >>>> before. Syslog follows >>>> >>>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/890276d2-116b-43f8-b51c-57bec5a1166dn%40googlegroups.com.
[weewx-user] Re: GW1000 output and database
8_batt': 'wh68_batt', 'windDir': 'winddir', 'windGust':
> 'gustspeed', 'windSpeed': 'windspeed', 'windchill': 'windchill',
> 'ws80_batt': 'ws80_batt', 'yearRain': 'rainyear'}
> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000:
> version is 0.1.0b11
> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000
> IP address not specified, attempting to discover GW1000...
> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000
> address is 192.168.1.6:45000
> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: poll
> interval is 60 seconds
> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: max
> tries is 3, retry wait time is 10 seconds
> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000:
> broadcast address 255.255.255.255:46000, socket timeout is 2 seconds
> Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: max
> age of API data to be used is 60 seconds
> Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG weewx.engine: Finished
> loading service user.gw1000.Gw1000Service
>
> What was your [GW1000] stanza when this was log was taken, if you did not
> have [[field_map]] then we need to see the log extract with [[field_map]].
>
> This also tells me that whilst the GW1000 was found twice at startup
> contact was subsequently lost with the GW1000 and it looks like contact was
> not re-established:
>
> Aug 20 20:02:58 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: Failed
> attempt 3 to send command 'CMD_GW1000_LIVEDATA': timed out
> Aug 20 20:02:58 raspberrypi weewx[31556] ERROR gw1000: user.gw1000: Failed
> to send command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Aug 20 20:02:58 raspberrypi weewx[31556] INFO gw1000: user.gw1000:
> Attempting to re-discover GW1000...
>
> Would certainly explain the lack of GW1000 data. Have you noticed these
> type of entries before? Is your GW1000 being allocated a fixed/static IP?
>
> Gary
>
>
> On Friday, 21 August 2020 12:20:03 UTC+10, Timothy Buchanan wrote:
>>
>> [[field_map]] makes all values null, including the ones that worked
>> before. Syslog follows
>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/865d3557-6fc9-4ac5-8bae-5d25160aead5n%40googlegroups.com.
Aug 21 09:48:59 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Aug 21 09:48:59 raspberrypi weewx[5075] INFO __main__: Initializing weewx
version 4.1.1
Aug 21 09:48:59 raspberrypi weewx[5075] INFO __main__: Using Python 2.7.16
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Aug 21 09:48:59 raspberrypi weewx[5075] INFO __main__: Platform
Linux-5.4.51-v7l+-armv7l-with-debian-10.4
Aug 21 09:48:59 raspberrypi weewx[5075] INFO __main__: Locale is 'en_US.UTF-8'
Aug 21 09:48:59 raspberrypi weewx[5075] INFO __main__: PID file is
/var/run/weewx.pid
Aug 21 09:48:59 raspberrypi weewx[5063]: Starting weewx weather system: weewx.
Aug 21 09:48:59 raspberrypi weewx[5079] INFO __main__: Using configuration file
/etc/weewx/weewx.conf
Aug 21 09:48:59 raspberrypi systemd[1]: Started LSB: weewx weather system.
Aug 21 09:48:59 raspberrypi weewx[5079] INFO __main__: Debug is 0
Aug 21 09:48:59 raspberrypi weewx[5079] INFO weewx.engine: Loading station type
WeatherFlowUDP (user.weatherflowudp)
Aug 21 09:48:59 raspberrypi weewxd: weatherflowudp: MainThread: driver version
is 1.03
Aug 21 09:48:59 raspberrypi weewxd: weatherflowudp: MainThread: sensor map is
{u'outTemp': u'air_temperature.AR-00017660.obs_air', u'outHumidity':
u'relative_humidity.AR-00017660.obs_air', u'pressure':
u'station_pressure.AR-00017660.obs_air', u'lightning_strikes':
u'lightning_strike_count.AR-00017660.obs_air', u'avg_distance':
u'lightning_strike_avg_distance.AR-00017660.obs_air', u'outTempBatteryStatus':
u'battery.AR-00017660.obs_air', u'windSpeed':
u'wind_speed.SK-00017445.rapid_wind', u'windDir':
u'wind_direction.SK-00017445.rapid_wind', u'windGust':
u'wind_gust.SK-00017445.obs_sky', u'lux': u'illuminance.SK-00017445.obs_sky',
u'UV': u'uv.SK-00017445.obs_sky', u'rain':
u'rain_accumulated.SK-00017445.obs_sky', u'windBatteryStatus':
u'battery.SK-00017445.obs_sky', u'radiation':
u'solar_radiation.SK-00017445.obs_sky', u'lightningYYY':
u'distance.AR-00017660.evt_strike', u'lightningZZZ':
u'energy.AR-00017660.evt_strike'}
Aug 21 09:48:59 raspberrypi weewxd: weatherflowudp: MainThread: *** Sensor
names per packet type
Aug 21 09:48:59 raspberrypi weewxd: weatherflowudp: MainThread: packet
rapid_wind: ('time_epoch', 'wind_speed', 'wind_direction')
Aug 21 09:48:59 raspbe
[weewx-user] Re: GW1000 output and database
[[field_map]] makes all values null, including the ones that worked before.
Syslog follows
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/d81fe0ba-3b93-4e3a-a7bb-5d8364d7641dn%40googlegroups.com.
Aug 20 20:01:29 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Aug 20 20:01:29 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Initializing weewx
version 4.1.1
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Using Python 2.7.16
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Platform
Linux-5.4.51-v7l+-armv7l-with-debian-10.4
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Locale is 'en_US.UTF-8'
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: PID file is
/var/run/weewx.pid
Aug 20 20:01:29 raspberrypi weewx[31540]: Starting weewx weather system: weewx.
Aug 20 20:01:29 raspberrypi systemd[1]: Started LSB: weewx weather system.
Aug 20 20:01:29 raspberrypi weewx[31556] INFO __main__: Using configuration
file /etc/weewx/weewx.conf
Aug 20 20:01:29 raspberrypi weewx[31556] INFO __main__: Debug is 1
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG __main__: Initializing engine
Aug 20 20:01:29 raspberrypi weewx[31556] INFO weewx.engine: Loading station
type WeatherFlowUDP (user.weatherflowudp)
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: driver version
is 1.03
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: sensor map is
{u'outTemp': u'air_temperature.AR-00017660.obs_air', u'outHumidity':
u'relative_humidity.AR-00017660.obs_air', u'pressure':
u'station_pressure.AR-00017660.obs_air', u'lightning_strikes':
u'lightning_strike_count.AR-00017660.obs_air', u'avg_distance':
u'lightning_strike_avg_distance.AR-00017660.obs_air', u'outTempBatteryStatus':
u'battery.AR-00017660.obs_air', u'windSpeed':
u'wind_speed.SK-00017445.rapid_wind', u'windDir':
u'wind_direction.SK-00017445.rapid_wind', u'windGust':
u'wind_gust.SK-00017445.obs_sky', u'lux': u'illuminance.SK-00017445.obs_sky',
u'UV': u'uv.SK-00017445.obs_sky', u'rain':
u'rain_accumulated.SK-00017445.obs_sky', u'windBatteryStatus':
u'battery.SK-00017445.obs_sky', u'radiation':
u'solar_radiation.SK-00017445.obs_sky', u'lightningYYY':
u'distance.AR-00017660.evt_strike', u'lightningZZZ':
u'energy.AR-00017660.evt_strike'}
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: *** Sensor
names per packet type
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet
rapid_wind: ('time_epoch', 'wind_speed', 'wind_direction')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_sky:
('time_epoch', 'illuminance', 'uv', 'rain_accumulated', 'wind_lull',
'wind_avg', 'wind_gust', 'wind_direction', 'battery', 'report_interval',
'solar_radiation', 'local_day_rain_accumulation', 'precipitation_type',
'wind_sample_interval')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_air:
('time_epoch', 'station_pressure', 'air_temperature', 'relative_humidity',
'lightning_strike_count', 'lightning_strike_avg_distance', 'battery',
'report_interval')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet
evt_precip: time_epoch
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet
evt_strike: ('time_epoch', 'distance', 'energy')
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service
weewx.engine.StdTimeSynch
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Finished loading
service weewx.engine.StdTimeSynch
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service
user.bme280wx.Bme280wx
Aug 20 20:01:29 raspberrypi weewxd: bme280: bme280wx configuration
{u'temperature_must_have': u'', u'humidityKeys': u'inHumidity',
u'pressureKeys': u'', u'pressure_must_have': u'', u'i2c_port': u'1',
u'humidity_must_have': u'', u'i2c_address': u'0x76', u'usUnits': u'US',
u'temperatureKeys': u'inTemp'}
Aug 20 20:01:29 raspberrypi weewxd: bme280: I2C port: 1
Aug 20 20:01:29 raspberrypi weewxd: bme280: I2C address: 0x76
Aug 20 20:01:29 raspberrypi weewxd: bme280: fallback default units: US
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Finished loading
service user.bme280wx.Bme280wx
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service
user.gw1000.Gw1000Service
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000 was
found at 192.168.1.6:45000
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: field map is
{'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind':
'daymaxwind', 'dewpoint':
[weewx-user] Re: GW1000 output and database
when >>> defining a field map entry the format is: >>> >>> WeeWX field name = GW1000 field name >>> >>> where: >>> GW1000 field name is the name of the GW1000 'field' that you >>> wish to map >>> WeeWX field name is the WeeWX field name you wish to contain >>> the data from the GW1000 'field' concerned. The WeeWX field name is the the >>> field name you will use in reports etc >>> >>> You can see what fields your GW1000 emits by running the GW1000 driver >>> directly with the --live-data command line option (the fields shown >>> when running the driver directly using the --test-service or >>> --test-driver command line options are WeeWX field names, ie they have >>> been mapped using the field map, fields shown using --live-data are >>> GW1000 'fields' ie they are unmapped). >>> >>> Gary >>> >>> On Thursday, 20 August 2020 08:15:29 UTC+10, Timothy Buchanan wrote: >>>> >>>> I installed GW1000 as a service and the test-service command gives this >>>> output: >>>> >>>> dateTime: 1597861672, dummyTemp: 96.3, extraHumid1: 26, extraTemp1: >>>> 85.1, inHumidity: 33, inTemp: 75.74, pressure: 22.2360805875, >>>> relbarometer: >>>> 753.0, soilMoist1: 15, usUnits: 1, wh31_ch1_batt: 0, wh51_ch1_batt: 0 >>>> >>>> In weewx.conf, I put this list of options: >>>> >>>> [GW1000] >>>> driver = user.gw1000 >>>> inTemp = extraTemp2 >>>> inHumidity = extraHumid2 >>>> extraTemp1 = extraTemp1 >>>> extraHumid1 = extraHumid1 >>>> soilMoist1 = soilMoist1 >>>> pressure = "" >>>> >>>> I chose these because inTemp is being used by another service. When I >>>> tried to use the data in my skin (modified exfoliation), I found that >>>> extraTemp2 and extraHumid2 are shown as NA. The other values are >>>> displayed. >>>> What did I do wrong here? Thanks for any help. >>>> >>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/1dc3e7f3-d025-45a7-b3c0-71384eb4f158n%40googlegroups.com.
[weewx-user] Re: GW1000 output and database
Thanks for the detailed reply; I'll try to be more clear. I have two services running, as indicated by this line: data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service The first service is an i2c sensor providing temp/humidity at the raspberry pi. It's options are so: [Bme280wx] temperature_must_have = "" humidityKeys = inHumidity pressureKeys = "" pressure_must_have = "" i2c_port = 1 humidity_must_have = "" i2c_address = 0x76 usUnits = US temperatureKeys = inTemp The sensor data are humidityKeys and temperatureKeys and they are mapped to inHumidity and inTemp. This service runs and reports properly; where my skin uses inTemp the data from the sensor is displayed. The GW1000 options are currently set so, following the instructions in your reply: [GW1000] driver = user.gw1000 [[field map]] extraTemp2 = inTemp extraHumid2 = inHumidity extraTemp1 = extraTemp1 extraHumid1 = extraHumid1 soilMoist1 = soilMoist1 Three of the fields provided by the GW1000 are the same in the database (the latter three), and they are reporting correctly. I want the GW1000 fields inTemp and inHumidity to map to the weewx database fields extraTemp2 and extraHumid2. That is not working with the field map as shown. Have I missed something? On Wednesday, August 19, 2020 at 6:03:58 PM UTC-6 gjr80 wrote: > Hi, > > I think we might need a bit of clarification as to what it is you are > trying to do. You say "inTemp is being used by another service", do you > mean that WeeWX field inTemp is being *provided* by another > service/driver (which has consequences for running the GW1000 driver as as > service) or do you mean WeeWX field inTemp is being *used* by another > service (which has no consequences for the GW1000 driver when run as a > service). Does the same apply for inHumidity? When you ran the GW1000 > driver directly with --test-service there was no extraTemp2 or extraHumid2 > fields and your field map does not map anything to these fields so I would > expect extraTemp2 and extraHumid2 to show as N/A in any reports. > > Perhaps you have a misunderstanding re the field map. The field map maps > GW000 'fields' to WeeWX fields. The GW1000 driver uses a default field map. > The default field map can be altered in two ways; you can replace the > entire default field map by defining your own field map using a > [[field_map]] stanza, or you can alter the default field map by listing > changes to the default field map in a [[field_map_extensions]] stanza. It > is not clear if you were attempting one of these approaches as you have no [[ > ]] level stanza in the config extra you posted. Also when defining a > field map entry the format is: > > WeeWX field name = GW1000 field name > > where: > GW1000 field name is the name of the GW1000 'field' that you wish > to map > WeeWX field name is the WeeWX field name you wish to contain the > data from the GW1000 'field' concerned. The WeeWX field name is the the > field name you will use in reports etc > > You can see what fields your GW1000 emits by running the GW1000 driver > directly with the --live-data command line option (the fields shown when > running the driver directly using the --test-service or --test-driver > command line options are WeeWX field names, ie they have been mapped using > the field map, fields shown using --live-data are GW1000 'fields' ie they > are unmapped). > > Gary > > On Thursday, 20 August 2020 08:15:29 UTC+10, Timothy Buchanan wrote: >> >> I installed GW1000 as a service and the test-service command gives this >> output: >> >> dateTime: 1597861672, dummyTemp: 96.3, extraHumid1: 26, extraTemp1: 85.1, >> inHumidity: 33, inTemp: 75.74, pressure: 22.2360805875, relbarometer: >> 753.0, soilMoist1: 15, usUnits: 1, wh31_ch1_batt: 0, wh51_ch1_batt: 0 >> >> In weewx.conf, I put this list of options: >> >> [GW1000] >> driver = user.gw1000 >> inTemp = extraTemp2 >> inHumidity = extraHumid2 >> extraTemp1 = extraTemp1 >> extraHumid1 = extraHumid1 >> soilMoist1 = soilMoist1 >> pressure = "" >> >> I chose these because inTemp is being used by another service. When I >> tried to use the data in my skin (modified exfoliation), I found that >> extraTemp2 and extraHumid2 are shown as NA. The other values are displayed. >> What did I do wrong here? Thanks for any help. >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9c04de5f-49b4-47f0-989f-7afd2f86fe0cn%40googlegroups.com.
[weewx-user] GW1000 output and database
I installed GW1000 as a service and the test-service command gives this output: dateTime: 1597861672, dummyTemp: 96.3, extraHumid1: 26, extraTemp1: 85.1, inHumidity: 33, inTemp: 75.74, pressure: 22.2360805875, relbarometer: 753.0, soilMoist1: 15, usUnits: 1, wh31_ch1_batt: 0, wh51_ch1_batt: 0 In weewx.conf, I put this list of options: [GW1000] driver = user.gw1000 inTemp = extraTemp2 inHumidity = extraHumid2 extraTemp1 = extraTemp1 extraHumid1 = extraHumid1 soilMoist1 = soilMoist1 pressure = "" I chose these because inTemp is being used by another service. When I tried to use the data in my skin (modified exfoliation), I found that extraTemp2 and extraHumid2 are shown as NA. The other values are displayed. What did I do wrong here? Thanks for any help. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/82408400-064e-4949-a242-54162cab5f5dn%40googlegroups.com.
Re: [weewx-user] Using more than one driver?
I installed the gw1000 driver, using sudo wee_extension --install=/var/tmp/gw1000-0.1.0b10.tar.gz and edited weewx.conf [[Services]] to read data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service but this broke the generation of reports. Editing back to data_services = user.bme280wx.Bme280wx fixed this. What went wrong? I don't have a gw1000 gateway running yet. Thanks again. On Tuesday, August 11, 2020 at 4:02:38 PM UTC-6 Timothy Buchanan wrote: > This is not yet listed on the wiki but a search found it on GitHub. Thanks > for calling my attention to it. > > On Tuesday, August 11, 2020 at 2:21:51 PM UTC-6 steep...@gmail.com wrote: > >> You cannot run two drivers in the same instance of WeeWX. However you can >> use the new weewx-gw1000 extension which can be run as a service at the >> same time as your Weatherflow driver. >> >> >> >> On Tue, 11 Aug 2020 at 21:03, Timothy Buchanan >> wrote: >> >>> I am running an nginx server displaying data from a Weatherflow station >>> and all is working ( http://millennialhouse.mynetgear.com/weatherserver/). >>> I would like to add data from an Ecowitt gateway using interceptor. Would I >>> need to run a separate instance of weewx and integrate the data with the >>> web server, or could I run weewx with two drivers? Thanks. >>> >>> -- >>> 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/b3900207-58f9-4bc0-82e3-e4f7451aea24n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/b3900207-58f9-4bc0-82e3-e4f7451aea24n%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/3c8a6c05-a906-409d-856c-2c72d83dd5d3n%40googlegroups.com.
Re: [weewx-user] Using more than one driver?
This is not yet listed on the wiki but a search found it on GitHub. Thanks for calling my attention to it. On Tuesday, August 11, 2020 at 2:21:51 PM UTC-6 steep...@gmail.com wrote: > You cannot run two drivers in the same instance of WeeWX. However you can > use the new weewx-gw1000 extension which can be run as a service at the > same time as your Weatherflow driver. > > > > On Tue, 11 Aug 2020 at 21:03, Timothy Buchanan > wrote: > >> I am running an nginx server displaying data from a Weatherflow station >> and all is working ( http://millennialhouse.mynetgear.com/weatherserver/). >> I would like to add data from an Ecowitt gateway using interceptor. Would I >> need to run a separate instance of weewx and integrate the data with the >> web server, or could I run weewx with two drivers? Thanks. >> >> -- >> 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/b3900207-58f9-4bc0-82e3-e4f7451aea24n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/b3900207-58f9-4bc0-82e3-e4f7451aea24n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0a0483d8-df69-42da-a441-c180d854e52cn%40googlegroups.com.
[weewx-user] Using more than one driver?
I am running an nginx server displaying data from a Weatherflow station and all is working ( http://millennialhouse.mynetgear.com/weatherserver/). I would like to add data from an Ecowitt gateway using interceptor. Would I need to run a separate instance of weewx and integrate the data with the web server, or could I run weewx with two drivers? Thanks. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/b3900207-58f9-4bc0-82e3-e4f7451aea24n%40googlegroups.com.
[weewx-user] Extension for Govee BT sensors?
Amazon sells cheap (12-13$) Govee temp/humidity sensors that link via BT to their app. Is anyone working on an extension that could get this into weewx? A search of the extension page didn't turn up anything? Thanks. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ad3a7062-5ac0-4e1b-a82a-635a69525db0n%40googlegroups.com.
[weewx-user] Graphic skin recommendations?
Is there a skin available that has a simple graphic design with a wind rose? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/b170f23b-3f31-4dbf-8e1b-6e36290a0a97%40googlegroups.com.
[weewx-user] Force auto-update of web page?
Now having a working weewx website (thanks to much help here), I am wondering if there is an easy way to force the loaded web page to update whenever weewx runs a report. I am using nginx server. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a3870dbd-1de8-4573-b186-edc58b0986f7%40googlegroups.com.
[weewx-user] Re: exfoliation skin: problem with current page display
I have simply removed that column as the information is covered elsewhere in the skin. Looks pretty good now. thanks again for your help. On Tuesday, October 22, 2019 at 5:29:15 PM UTC-6, gjr80 wrote: > > To properly display $day.maxSolarRad.xxx tags will require you to add the > field maxSolarRad to your database schema. maxSolarRad is a derived > observation that is calculated by WeeWX and added to loop packets and > archive records. The current maxSolarRad value (ie $current.maxSolarRad) > can be displayed without any change to the schema, but aggregates or plots > require WeeWX to be archiving the underlying data. If you want to go ahead > and add maxSolarRad to the database schema refer to the Adding a new type > to the database <http://weewx.com/docs/customizing.htm#add_archive_type> > section of the Customization Guide <http://weewx.com/docs/customizing.htm> > . > > As for the other issue with the missing forecast data I don't use the > Exfoliation skin nor do I use the NWS forecast so it's going to take a > little time before I can provide any assistance there. > > Gary > > On Tuesday, 22 October 2019 05:44:51 UTC+10, Timothy Buchanan wrote: >> >> I am using the exfoliation skin and have gotten all the pages working, >> except there is a problem with the display of the "current" page. I've >> attached a file showing the problem. The current weather source is set in >> the weewx.conf Forecast extension as NWS with lid = COZ081 and foid = PUB. >> The three-day forecast is working properly in the third column, but the >> forecast conditions in the second column are missing. There is also a >> formatting statement shown there. I am using the standard index.html.tmpl >> as it comes with the extension. Any help (especially from the extension's >> author!) is appreciated. >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/5b5ad75c-ed5c-42fb-aac4-2576c0d0fcfd%40googlegroups.com.
[weewx-user] exfoliation skin: problem with current page display
I am using the exfoliation skin and have gotten all the pages working, except there is a problem with the display of the "current" page. I've attached a file showing the problem. The current weather source is set in the weewx.conf Forecast extension as NWS with lid = COZ081 and foid = PUB. The three-day forecast is working properly in the third column, but the forecast conditions in the second column are missing. There is also a formatting statement shown there. I am using the standard index.html.tmpl as it comes with the extension. Any help (especially from the extension's author!) is appreciated. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/872f67fa-f932-43b1-a72b-8bfd440ee557%40googlegroups.com.
[weewx-user] Re: exfoliation skin not generating reports
On the forecasting extension wiki, I found this instruction to add the following to weewx.conf if using seasons: [[[CheetahGenerator]]] search_list_extensions = user.forecast.ForecastVariables I'm not using seasons, but I added this code to the exfoliations section, and data appeared on the current page and the forecast page. (It would be very helpful if this instruction were added to the extension section of the forecasting wiki.) The current page is still missing data. I've attached a jpg to illustrate. Where would I look to supply this data? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8851d06a-8304-4455-a98a-d374c1fe52c7%40googlegroups.com.
[weewx-user] Re: exfoliation skin not generating reports
Thanks, I did that and managed to get exfoliation working, all except the forecast page. Syslog isn't much help there as it simply says "Skipping forecast.html." On the forecast page of the extension skin, it says "forecast_strip: forecast search list extension is not installed". I've installed the forecast extension and the forecast skin is working properly, so I'm guessing an include is missing in exfoliation. Where (template file?) and how would I include the forecast extension in the exfoliation skin? Thanks. On Friday, October 18, 2019 at 4:12:22 PM UTC-6, gjr80 wrote: > > Hi, > > Could be any one of many reasons. Impossible to say more without logs. In > weewx.conf set debug = 1, restart WeeWX and wait for at least two report > cycles to complete. Post the log from startup through until the two report > cycles have completed. > > Gary > > On Saturday, 19 October 2019 08:04:21 UTC+10, Timothy Buchanan wrote: >> >> I have installed or turned on several skins (smartphone, forecast, neowx, >> and Washboard). They are each generating reports in their respective >> folders in /var/www/html/weewx. They can be seen in the browser and update. >> >> I installed exfoliation and it is not generating folders or reports. Here >> are the lines from weewx.conf on the skins: >> >> # Where the generated reports should go, relative to WEEWX_ROOT >> HTML_ROOT = /var/www/html/weewx >> >> [[SeasonsReport]] >> # The SeasonsReport uses the 'Seasons' skin, which contains the >> # images, templates and plots for the report. >> skin = Seasons >> enable = true >> HTML_ROOT = /var/www/html/weewx/seasons >> >> [[SmartphoneReport]] >> # The SmartphoneReport uses the 'Smartphone' skin, and the images >> and >> # files are placed in a dedicated subdirectory. >> skin = Smartphone >> enable = true >> HTML_ROOT = /var/www/html/weewx/smartphone >> >> [[MobileReport]] >> # The MobileReport uses the 'Mobile' skin, and the images and >> files >> # are placed in a dedicated subdirectory. >> skin = Mobile >> enable = false >> HTML_ROOT = /var/www/html/weewx/mobile >> >> [[forecast]] >> HTML_ROOT = /var/www/html/weewx/forecast >> skin = forecast >> enable = false >> >> [[exfoliation]] >> HTML_ROOT = /var/www/html/weewx/exfoliation >> skin = exfoliation >> enable = true >> >> [[neowx]] >> HTML_ROOT = /var/www/html/weewx/neowx >> skin = neowx >> enable = true >> >> [[Washboard]] >> HTML_ROOT = /var/www/html/weewx/Washboard >> skin = Washboard >> enable = true >> >> [[StandardReport]] >> # This is the old "Standard" skin. By default, it is not enabled. >> #skin = Washboard >> enable = false >> >> Why is exfoliation not generating reports? Thanks. >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/1f10fdab-c436-4205-88d9-b01a8dac5866%40googlegroups.com.
[weewx-user] exfoliation skin not generating reports
I have installed or turned on several skins (smartphone, forecast, neowx, and Washboard). They are each generating reports in their respective folders in /var/www/html/weewx. They can be seen in the browser and update. I installed exfoliation and it is not generating folders or reports. Here are the lines from weewx.conf on the skins: # Where the generated reports should go, relative to WEEWX_ROOT HTML_ROOT = /var/www/html/weewx [[SeasonsReport]] # The SeasonsReport uses the 'Seasons' skin, which contains the # images, templates and plots for the report. skin = Seasons enable = true HTML_ROOT = /var/www/html/weewx/seasons [[SmartphoneReport]] # The SmartphoneReport uses the 'Smartphone' skin, and the images and # files are placed in a dedicated subdirectory. skin = Smartphone enable = true HTML_ROOT = /var/www/html/weewx/smartphone [[MobileReport]] # The MobileReport uses the 'Mobile' skin, and the images and files # are placed in a dedicated subdirectory. skin = Mobile enable = false HTML_ROOT = /var/www/html/weewx/mobile [[forecast]] HTML_ROOT = /var/www/html/weewx/forecast skin = forecast enable = false [[exfoliation]] HTML_ROOT = /var/www/html/weewx/exfoliation skin = exfoliation enable = true [[neowx]] HTML_ROOT = /var/www/html/weewx/neowx skin = neowx enable = true [[Washboard]] HTML_ROOT = /var/www/html/weewx/Washboard skin = Washboard enable = true [[StandardReport]] # This is the old "Standard" skin. By default, it is not enabled. #skin = Washboard enable = false Why is exfoliation not generating reports? Thanks. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/618006b0-52a7-4fb2-bc92-962dd1c3202f%40googlegroups.com. # configuration file for the exfoliation skin # $Id: skin.conf 1779 2017-12-10 22:04:07Z mwall $ # The exfoliation-for-weewx skin was created by Matthew Wall. # # This skin can be copied, modified, and distributed as long as this notice # is included in any derivative work. [Extras] version = 0.45 # If you have a Google Analytics ID, specify it here: #googleAnalyticsId = UA-12345678-1 # which blocks should be displayed on the 'current' page? current_show_inside = false current_show_celestial = true current_show_tides = false current_show_radar = true current_show_forecast_summary = false current_show_forecast_table = true # which forecast data should be displayed inline on the 'current' page? current_forecast_source = NWS # should the forecast page be displayed? show_forecast_page = true # should the history page be displayed? show_history_page = true # should the almanac page be displayed? show_almanac_page = true # should the station health page be displayed? show_station_page = false # which time periods should be options on the station page? station_periods = day, week, month # which station health indicators should be displayed on the station page? station_metrics = rx, battery # the cmon extension provides additional indicators #station_metrics = rx, battery, cpu, load, disk, mem, net, ups # should the links page be displayed? show_links_page = true # should the RSS link be displayed on the 'links' page? links_show_rss = true # the following are optional - they control what is displayed in the # 'links' page. replace with a URL for your location, or comment to # remove any one from display. # radar links_radar_local_img = http://radar.weather.gov/ridge/lite/N0R/PUX_loop.gif links_radar_regional_img = http://radar.weather.gov/ridge/Conus/Loop/northrockies_loop.gif links_radar_regional_img = http://radar.weather.gov/ridge/Conus/Loop/southrockies_loop.gif #links_radar_national_img = http://radar.weather.gov/Conus/RadarImg/latest.gif # forecasts links_local_forecast_url = http://forecast.weather.gov/MapClick.php?TextType=1=PUX=38.8321=-104.9313 #links_marine_forecast_url = http://forecast.weather.gov/shmrn.php?mz=anz230 # table of tides #links_tide_table_url = 'http://ma.usharbors.com/monthly-tides/Massachusetts-Boston%20Harbor%2CSouth%20Shore/Boston%20Harbor' # infrared links_satellite_ir_img = http://www.goes.noaa.gov/GIFS/ECIR.JPG # visible spectrum links_satellite_vs_img = http://www.goes.noaa.gov/GIFS/ECVS.JPG # water vapor links_satellite_wv_img = http://www.goes.noaa.gov/GIFS/ECWV.JPG # thermal links_satellite_i8_img =
[weewx-user] Re: Using fstab causes weewx to not update
Thanks! I will try again, knowing this. On Friday, October 18, 2019 at 7:00:31 AM UTC-6, Walter Smith wrote: > > I did this about a week ago. It changes the URL where the reports are. > On my Pi it changed the Seasons report URL from > http://192.168.0.111/weewx/index.html > to > http://192.168.0.111/weewx/reports/index.html > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cfc6f190-8195-40e8-8218-894073d3ed56%40googlegroups.com.
[weewx-user] Can't download forecasting extension
The link to download the forecasting extension is not working (http://lancet.mit.edu/mwall/projects/weather/releases/weewx-forecast-3.3.2.tgz). Is there another place I can get this file? Thanks. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f3542931-ee7d-44ed-8a40-a6b28ee3a180%40googlegroups.com.
[weewx-user] Using fstab causes weewx to not update
I am using nginx as the web server for weewx on an RPi3, and all works well
until I try to minimize writes on the SD as suggested to prolong its life.
Once I do that, the web page loads but will never update. Here are the
exact commands I used (deb install):
1. echo "weewx_reports /var/weewx/reports tmpfs
size=20M,noexec,nosuid,nodev 0 0" | sudo tee -a /etc/fstab
2. sudo mkdir -p /var/weewx/reports
3. sudo mount -a
4. sudo sed -i -e 's%HTML_ROOT =.*%HTML_ROOT = /var/weewx/reports%'
/etc/weewx/weewx.conf
5. sudo /etc/init.d/weewx stop
6. sudo /etc/init.d/weewx start
7. sudo ln -s /var/weewx/reports /var/www/html/weewx
8. sudo /etc/init.d/nginx restart
I am using the /etc/nginx/sites-available/default file. I tried replacing
the server name in the default file with this:
server {
...
location /weewx {
alias /var/www/html/weewx/index.html;
}
}
as recommended on another of the wiki pages, but nginx will not start with that
configuration. nginx finds the weewx page with the default file. Any
suggestions to make this work? Thanks.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/2471ea4e-2805-401e-aa17-1073ad706d6f%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
Thanks to the patient help and advice from many members here, I now have the weewx web page running and displaying data, though it still needs some tuning. My problems were from three sources: 1. I didn't know about setting the sensor parameters in the driver configuration, though it is obvious in retrospect. After that, I got packets, but nothing changed on the web page. 2. The instructions I found for saving weewx reports to a RAM file may have been misleading. I deleted all that and, for good measure, purged and re-installed weewx. 3. The lower pressure limit was far too high for Colorado. I set it to 18. Now I have a working web page. Most data is the same or very close to what is shown in the WF app, except for barometric pressure which is way off. The app shows 30.274 now, for example, while weewx shows 29.766. I have the weewx altitude and the WF sensor altitude set to the same value, 8475 feet (both sensors are on the ground now). What adjustments need to be made here? On Tuesday, October 15, 2019 at 8:32:26 AM UTC-6, vince wrote: > > On Monday, October 14, 2019 at 7:03:25 PM UTC-7, gjr80 wrote: >> >> >> The following indicates you have an issue with pressure data from the >> station/driver: >> >> Oct 14 14:05:26 raspberrypi weewx[8036]: engine: 2019-10-14 14:05:24 MDT >> (1571083524) LOOP value 'pressure' 21.92306272 outside limits (24.0, 34.5) >> >> > He indicated he's at 8500 feet elevation (wow) so that is likely related. > Personally I'd just up the limits that are acceptable. > > Agree with debug=1 as the next step of course. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/eee1cf49-197e-46fc-ae3b-91c50ae2c7a1%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
I answered my last question by myself. starting weewx not as daemon gives me data. everything seems to be there except pressure, altimeter and barometer. That may have to do with the altitude here (8500 feet), although I put that into the config file. If you can advise me where index.html normally is kept (the main directory is /home/weewx), then I will try to figure out how to get nginx to look there. On Monday, October 14, 2019 at 6:17:58 PM UTC-6, vince wrote: > > On Monday, October 14, 2019 at 4:27:11 PM UTC-7, Timothy Buchanan wrote: >> >> Ok, here is an extract from the syslog, from 14:04:53 when weewx started, >> to 14:26:20 when it stopped. It was running as daemon with log raw packets >> true. Also attached is the weewx.conf file. What can you tell from these? >> Thanks. >> >> > Looks like it's hearing the station quite fine. What is the problem at > this time ? > > My guess (guess) is that you have your weewx.conf set to put the output in > one place, and your web server (if there is one installed) to look in a > different place for the data. > > This is a very unusual place for HTML files > HTML_ROOT = /var/weewx/reports > > See if there is anything in there with current timestamps. Open the > index.html there in a browser and see what it looks like. > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/18b04124-3cd8-4682-908d-d45ff9cfebb3%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
I was following nginx server instructions I found, which were as follows: 1. At this point WeeWX is technically installed, however many individuals will want to present the WeeWX reports via webpage. In this case, we’ll install nginx, which is a lightweight webserver 1. *sudo apt-get install nginx* 1. More details on this can be found here: http://www.weewx.com/docs/usersguide.htm#integrating_with_webserver 2. Configure WeeWX to minimize disk IO 1. Why do we need to do this? Since Raspberry PI’s leverage SD cards, there is typically a finite number of reads/writes to the SD Card. In this case, it is recommended to either leverage an external database/fileserver for WeeWX to write its reports. Alternatively, we can also configure WeeWX to leverage ram to host the reports, which will prevent IO to the SD card (in this case, theoretically increasing the life of the drive) 1. Three approaches are outlined here <https://github.com/weewx/weewx/wiki/Minimize-writes-on-SD-cards>–in this guide I’ll reflect the GitHub page in saving reports to a temporary file system using tmpfs 1. Add an entry to fstab 1. *echo "weewx_reports /var/weewx/reports tmpfs size=20M,noexec,nosuid,nodev 0 0" | sudo tee -a /etc/fstab* 2. Mount the new file system 1. *sudo mkdir -p /var/weewx/reports* 2. *sudo mount -a* 3. Update weewx.config file to point to new directory 1. *sudo sed -i -e 's%HTML_ROOT =.*%HTML_ROOT = /var/weewx/reports%' /etc/weewx/weewx.conf* 4. Restart WeeWX service 1. *sudo service weewx restart* 5. Create symbolic link to point webserver to the reports 1. *sudo ln -s /var/weewx/reports /var/www/html/weewx* 6. Give the web server the ability to read from the directory 1. *sudo chmod -R 755 /var/www/html/weewx* At this point, go ahead and browse out to *http://youripaddress/weewx/ <http://youripaddress/weewx/>* to see your weather. (end) Should I try to undo all this, and where should the html files be? I have looked at the index.html in the following directories: /home/weewx/public_html/index.html /var/wewx/reports/index.html /var/www/html/wewx/index.html They each show the same simulator page. Where else can I look? Where could I look to see if there are reports, without going through a web page? If I can see data that weewx is collecting then I'll worry about how to get it into a web page. thanks again. On Monday, October 14, 2019 at 6:17:58 PM UTC-6, vince wrote: > > On Monday, October 14, 2019 at 4:27:11 PM UTC-7, Timothy Buchanan wrote: >> >> Ok, here is an extract from the syslog, from 14:04:53 when weewx started, >> to 14:26:20 when it stopped. It was running as daemon with log raw packets >> true. Also attached is the weewx.conf file. What can you tell from these? >> Thanks. >> >> > Looks like it's hearing the station quite fine. What is the problem at > this time ? > > My guess (guess) is that you have your weewx.conf set to put the output in > one place, and your web server (if there is one installed) to look in a > different place for the data. > > This is a very unusual place for HTML files > HTML_ROOT = /var/weewx/reports > > See if there is anything in there with current timestamps. Open the > index.html there in a browser and see what it looks like. > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/b2eb20c7-dc40-4a0e-ba27-c547815a196d%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
Thank you Vince and mwall for pointing out that I needed to change the sensor serial numbers in config. I did that but unhappily it's still not working. Before I had to leave I set weewx to log raw packets. When I get back I'll post the syslog for two or more archive periods. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/14a7ea03-ecc8-4d3d-82e8-aeb622404564%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
Yes, thanks, I understand that. How can I find out why WeeWx is not receiving data? On Sunday, October 13, 2019 at 8:33:11 PM UTC-6, gjr80 wrote: > > Never said the station wasn’t producing data. You asked why ‘Simulator’ is > still being shown, it is simply a symptom of WeeWX not receiving data from > the driver. > > Gary -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cf04d379-287e-4842-a785-52ee43eff8fb%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
The station is producing data. I can see it in the WFapp, and on the WF online map. The rpi is apparently picking up UDP packets per the python listen script. So why is WeeWx "not receiving any data?" Any leads to troubleshooting this would be appreciated. On Sunday, October 13, 2019 at 7:17:15 PM UTC-6, gjr80 wrote: > > You can ignore the 'Simulator' web page, it is an old page generated from > when you were running the simulator. It is clear from the log WeeWX is > using the weatherflow driver. WeeWX is not receiving any data from the > driver so hence no archive records are produced and hence no reports being > produced/updated. Once you have data it will be fine. > > Gary > > On Monday, 14 October 2019 11:06:19 UTC+10, Timothy Buchanan wrote: >> >> I've now run listen with -d set and got these attached results. It does >> seem as if the rpi is picking up the UDP packets, but not displaying them. >> Also, the web page continues to say "Simulator." >> >> On Sunday, October 13, 2019 at 12:47:45 PM UTC-6, vince wrote: >>> >>> On Sunday, October 13, 2019 at 10:04:09 AM UTC-7, Timothy Buchanan wrote: >>>> >>>> I set up a WeatherFlow station per their instructions, and it is >>>> feeding correct data to their app. I installed the weatherflowudp >>>> extension >>>> (using a Pi3), and wee_extension --list shows Version 1.03 as installed. >>>> There is a file weatherflowudp.py in /usr/share/wewx/user. I edited the >>>> /etc/weewx/weewx.conf as so: >>>> >>>> The file at /var/log/syslog shows the weewx in listening for UDP at >>>> on port 50222, but times out. >>>> What have I neglected to do? Thanks for help. >>>> >>> >>> I'm not quite seeing anything obvious. >>> >>> If you're comfortable running python stuff, you could try running my >>> standalone WeatherFlow UDP listener to verify your gear is hearing the >>> broadcast messages (which would validate the pi, taking weewx out of the >>> question for the moment) >>> >>> >>>- change share_socket to True so the weewx extension can let other >>>apps listen for the broadcasts simultaneously >>>- stop weewx (for now) >>> >>> >>>- grab my listener from >>>https://github.com/vinceskahan/weatherflow-udp-listener and follow >>>the Installation instructions >>>- you can run it via "python listen.py --raw" to have it just dump >>>what it sees to the screen. You'll see wind info in 3 secs if you have >>>rapid_wind enabled, but you'll see hub status in 10 secs or so >>> regardless. >>> If 'anything' is reported then your pi is hearing the broadcasts and we >>>can move back to validating weewx. >>>- hit control-C to stop it (you might need to hit that twice) >>> >>> >>> >>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c5f40683-680b-4e75-814a-4337de371e7d%40googlegroups.com.
[weewx-user] Re: Installed extension and edited config, but still shows simulator
I've now run listen with -d set and got these attached results. It does seem as if the rpi is picking up the UDP packets, but not displaying them. Also, the web page continues to say "Simulator." On Sunday, October 13, 2019 at 12:47:45 PM UTC-6, vince wrote: > > On Sunday, October 13, 2019 at 10:04:09 AM UTC-7, Timothy Buchanan wrote: >> >> I set up a WeatherFlow station per their instructions, and it is feeding >> correct data to their app. I installed the weatherflowudp extension (using >> a Pi3), and wee_extension --list shows Version 1.03 as installed. There is >> a file weatherflowudp.py in /usr/share/wewx/user. I edited the >> /etc/weewx/weewx.conf as so: >> >> The file at /var/log/syslog shows the weewx in listening for UDP at >> on port 50222, but times out. >> What have I neglected to do? Thanks for help. >> > > I'm not quite seeing anything obvious. > > If you're comfortable running python stuff, you could try running my > standalone WeatherFlow UDP listener to verify your gear is hearing the > broadcast messages (which would validate the pi, taking weewx out of the > question for the moment) > > >- change share_socket to True so the weewx extension can let other >apps listen for the broadcasts simultaneously >- stop weewx (for now) > > >- grab my listener from >https://github.com/vinceskahan/weatherflow-udp-listener and follow the >Installation instructions >- you can run it via "python listen.py --raw" to have it just dump >what it sees to the screen. You'll see wind info in 3 secs if you have >rapid_wind enabled, but you'll see hub status in 10 secs or so regardless. > If 'anything' is reported then your pi is hearing the broadcasts and we >can move back to validating weewx. >- hit control-C to stop it (you might need to hit that twice) > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/47af6bc3-acc5-4cf7-a8cb-67a260357d91%40googlegroups.com. pi@raspberrypi:~/Downloads/weatherflow-udp-listener-master $ python listen.py -d rapid_wind => ts = 1571014891 mps = 0.89 dir = 218 hub_status => ts = 1571014892 firmware_revision = 114 uptime = 33319 rssi = -57 rapid_wind => ts = 1571014894 mps = 0.09 dir = 241 rapid_wind => ts = 1571014897 mps = 0.45 dir = 88 device_status => device_type = sky ts = 1571014900 uptime = 34675 voltage = 2.65 firmware_revision = 43 rssi = -52 hub_rssi = -46 obs_sky=> timestamp = 1571014900 uv = 0.0 rain_accumulated = 0.0 wind_lull = 0.0 wind_avg = 0.62 wind_gust = 1.56 wind_direction = 171 rapid_wind => ts = 1571014900 mps = 0.67 dir = 106 hub_status => ts = 1571014902 firmware_revision = 114 uptime = 33329 rssi = -53 device_status => device_type = air ts = 1571014902 uptime = 34959 voltage = 3.21 firmware_revision = 22 rssi = -36 hub_rssi = -36 obs_air=> ts = 1571014902 station_pressure = 744.4 temperature = 22.21 relative_humidity = 28 lightning_strikes = 0 lightning_avg_km = 0 rapid_wind => ts = 1571014903 mps = 0.18 dir = 164 rapid_wind => ts = 1571014906 mps = 0.94 dir = 203 rapid_wind => ts = 1571014909 mps = 0.67 dir = 152 hub_status => ts = 1571014912 firmware_revision = 114 uptime = 9 rssi = -57 rapid_wind => ts = 1571014912 mps = 0.49 dir = 224 rapid_wind => ts = 1571014915 mps = 1.79 dir = 196
[weewx-user] Re: Installed extension and edited config, but still shows simulator
weewx runs as a daemon on boot here, so I used sudo /etc/init.d/weewx stop,
then started it again. I attach an extract of syslog from the stop/start
for some minutes after. it looks like weewx starts properly and begins to
listen, but never gets data or times out.
I attached wewx.conf to an earlier posting; perhaps someone who has a
working WeatherFlow setup can look at that.
I used Vince's listen script and the output from that is attached to an
earlier posting. The rpi seems to be getting hub information but no sensor
data.
All help is greatly appreciated.
On Sunday, October 13, 2019 at 4:45:02 PM UTC-6, mwall wrote:
>
>
>
> On Sunday, October 13, 2019 at 1:43:31 PM UTC-4, Timothy Buchanan wrote:
>>
>>
>> Attached syslog file.
>>
>
> please send the log starting just before weewx starts up
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/9848bfbc-fb55-4fe1-b0ed-1ccdea99a14f%40googlegroups.com.
Oct 13 17:18:10 raspberrypi systemd[1]: Stopping LSB: weewx weather system...
Oct 13 17:18:10 raspberrypi weewx[1072]: engine: Main loop exiting. Shutting
engine down.
Oct 13 17:18:10 raspberrypi weewx[1072]: engine: Terminating weewx version 3.9.2
Oct 13 17:18:10 raspberrypi weewx[1139]: Stopping weewx weather system: weewx.
Oct 13 17:18:10 raspberrypi systemd[1]: weewx.service: Succeeded.
Oct 13 17:18:10 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Oct 13 17:18:50 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Oct 13 17:18:50 raspberrypi weewx[1217]: engine: Initializing weewx version
3.9.2
Oct 13 17:18:50 raspberrypi weewx[1217]: engine: Using Python 2.7.16 (default,
Apr 6 2019, 01:42:57) #012[GCC 8.2.0]
Oct 13 17:18:50 raspberrypi weewx[1217]: engine: Platform
Linux-4.19.75-v7+-armv7l-with-debian-10.1
Oct 13 17:18:50 raspberrypi weewx[1217]: engine: Locale is 'en_US.UTF-8'
Oct 13 17:18:50 raspberrypi weewx[1217]: engine: pid file is /var/run/weewx.pid
Oct 13 17:18:50 raspberrypi weewx[1221]: engine: Using configuration file
/etc/weewx/weewx.conf
Oct 13 17:18:50 raspberrypi weewx[1221]: engine: Loading station type
WeatherFlowUDP (user.weatherflowudp)
Oct 13 17:18:50 raspberrypi weewx[1206]: Starting weewx weather system: weewx.
Oct 13 17:18:50 raspberrypi systemd[1]: Started LSB: weewx weather system.
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: driver
version is 1.03
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: sensor map
is {'outTemp': 'air_temperature.AR-.obs_air', 'outHumidity':
'relative_humidity.AR-.obs_air', 'pressure':
'station_pressure.AR-.obs_air', 'outTempBatteryStatus':
'battery.AR-.obs_air', 'windSpeed':
'wind_speed.SK-1234.rapid_wind', 'windDir':
'wind_direction.SK-1234.rapid_wind', 'UV': 'uv.SK-1234.obs_sky',
'rain': 'rain_accumulated.SK-1234.obs_sky', 'windBatteryStatus':
'battery.SK-1234.obs_sky', 'radiation':
'solar_radiation.SK-1234.obs_sky'}
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: *** Sensor
names per packet type
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: packet
rapid_wind: ('time_epoch', 'wind_speed', 'wind_direction')
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: packet
obs_sky: ('time_epoch', 'illuminance', 'uv', 'rain_accumulated', 'wind_lull',
'wind_avg', 'wind_gust', 'wind_direction', 'battery', 'report_interval',
'solar_radiation', 'local_day_rain_accumulation', 'precipitation_type',
'wind_sample_interval')
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: packet
obs_air: ('time_epoch', 'station_pressure', 'air_temperature',
'relative_humidity', 'lightning_strike_count', 'lightning_strike_avg_distance',
'battery', 'report_interval')
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: packet
evt_precip: time_epoch
Oct 13 17:18:50 raspberrypi weewx[1221]: weatherflowudp: MainThread: packet
evt_strike: ('time_epoch', 'distance', 'energy')
Oct 13 17:18:50 raspberrypi weewx[1221]: engine: StdConvert target unit is 0x1
Oct 13 17:18:50 raspberrypi weewx[1221]: wxcalculate: The following values will
be calculated: barometer=prefer_hardware, windchill=prefer_hardware,
dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware,
windrun=prefer_hardware, heatindex=prefer_hardware,
maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware,
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
cloudbase=prefer_hardware
Oct 13 17:18:50 raspberrypi weewx[1221]: wxcalculate: The following algorithms
will be used for calculations: altimeter=a
[weewx-user] Re: Installed extension and edited config, but still shows simulator
And here is the weewx.conf file. On Sunday, October 13, 2019 at 1:41:08 PM UTC-6, Timothy Buchanan wrote: > > This is the output from listen --raw. It keeps repeating these lines. > > On Sunday, October 13, 2019 at 12:47:45 PM UTC-6, vince wrote: >> >> On Sunday, October 13, 2019 at 10:04:09 AM UTC-7, Timothy Buchanan wrote: >>> >>> I set up a WeatherFlow station per their instructions, and it is feeding >>> correct data to their app. I installed the weatherflowudp extension (using >>> a Pi3), and wee_extension --list shows Version 1.03 as installed. There is >>> a file weatherflowudp.py in /usr/share/wewx/user. I edited the >>> /etc/weewx/weewx.conf as so: >>> >>> The file at /var/log/syslog shows the weewx in listening for UDP at >>> on port 50222, but times out. >>> What have I neglected to do? Thanks for help. >>> >> >> I'm not quite seeing anything obvious. >> >> If you're comfortable running python stuff, you could try running my >> standalone WeatherFlow UDP listener to verify your gear is hearing the >> broadcast messages (which would validate the pi, taking weewx out of the >> question for the moment) >> >> >>- change share_socket to True so the weewx extension can let other >>apps listen for the broadcasts simultaneously >>- stop weewx (for now) >> >> >>- grab my listener from >>https://github.com/vinceskahan/weatherflow-udp-listener and follow >>the Installation instructions >>- you can run it via "python listen.py --raw" to have it just dump >>what it sees to the screen. You'll see wind info in 3 secs if you have >>rapid_wind enabled, but you'll see hub status in 10 secs or so >> regardless. >> If 'anything' is reported then your pi is hearing the broadcasts and we >>can move back to validating weewx. >>- hit control-C to stop it (you might need to hit that twice) >> >> >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f4348989-c172-4544-b453-888c68fcfff5%40googlegroups.com. # WEEWX CONFIGURATION FILE # # Copyright (c) 2009-2019 Tom Keffer # See the file LICENSE.txt for your rights. ## # This section is for general configuration information. # Set to 1 for extra debug info, otherwise comment it out or set to zero debug = 0 # Root directory of the weewx data file hierarchy for this station WEEWX_ROOT = / # Whether to log successful operations log_success = True # Whether to log unsuccessful operations log_failure = True # How long to wait before timing out a socket (FTP, HTTP) connection socket_timeout = 20 # Do not modify this. It is used when installing and updating weewx. version = 3.9.2 ## # This section is for information about the station. [Station] # Description of the station location location = "Crystal Park, Manitou Springs, Colorado" # Latitude and longitude in decimal degrees latitude = 38.832118 longitude = -104.93125 # Altitude of the station, with unit it is in. This is downloaded from # from the station if the hardware supports it. altitude = 8500, foot # Set to type of station hardware. There must be a corresponding stanza # in this file with a 'driver' parameter indicating the driver to be used. # station_type = Simulator station_type = WeatherFlowUDP # If you have a website, you may specify an URL #station_url = http://www.example.com # The start of the rain year (1=January; 10=October, etc.). This is # downloaded from the station if the hardware supports it. rain_year_start = 1 # Start of week (0=Monday, 6=Sunday) week_start = 6 ## [WeatherFlowUDP] driver = user.weatherflowudp log_raw_packets = False udp_address = # udp_address = 0.0.0.0 # udp_address = 255.255.255.255 udp_port = 50222 udp_timeout = 90 share_socket = False [[sensor_map]] outTemp = air_temperature.AR-.obs_air outHumidity = relative_humidity.AR-.obs_air pressure = station_pressure.AR-.obs_air # lightning_strikes = lightning_strike_count.AR-.obs_air # avg_distance = lightning_strike_avg_distance.AR-
[weewx-user] Re: Installed extension and edited config, but still shows simulator
This is the output from listen --raw. It keeps repeating these lines.
On Sunday, October 13, 2019 at 12:47:45 PM UTC-6, vince wrote:
>
> On Sunday, October 13, 2019 at 10:04:09 AM UTC-7, Timothy Buchanan wrote:
>>
>> I set up a WeatherFlow station per their instructions, and it is feeding
>> correct data to their app. I installed the weatherflowudp extension (using
>> a Pi3), and wee_extension --list shows Version 1.03 as installed. There is
>> a file weatherflowudp.py in /usr/share/wewx/user. I edited the
>> /etc/weewx/weewx.conf as so:
>>
>> The file at /var/log/syslog shows the weewx in listening for UDP at
>> on port 50222, but times out.
>> What have I neglected to do? Thanks for help.
>>
>
> I'm not quite seeing anything obvious.
>
> If you're comfortable running python stuff, you could try running my
> standalone WeatherFlow UDP listener to verify your gear is hearing the
> broadcast messages (which would validate the pi, taking weewx out of the
> question for the moment)
>
>
>- change share_socket to True so the weewx extension can let other
>apps listen for the broadcasts simultaneously
>- stop weewx (for now)
>
>
>- grab my listener from
>https://github.com/vinceskahan/weatherflow-udp-listener and follow the
>Installation instructions
>- you can run it via "python listen.py --raw" to have it just dump
>what it sees to the screen. You'll see wind info in 3 secs if you have
>rapid_wind enabled, but you'll see hub status in 10 secs or so regardless.
> If 'anything' is reported then your pi is hearing the broadcasts and we
>can move back to validating weewx.
>- hit control-C to stop it (you might need to hit that twice)
>
>
>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/cff1456e-8cc2-4d2a-acbd-fcb7d80a46cd%40googlegroups.com.
pi@raspberrypi:~/Downloads/weatherflow-udp-listener-master $ python listen.py
--raw
raw data: {"hub_sn": "HB-00014675", "ob": [1570995308, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"firmware_revision": "114", "fs": [1, 0, 15675411, 524288],
"mqtt_stats": [1, 0], "radio_stats": [5, 1, 0, 3], "reset_flags": "PIN,WDG",
"rssi": -56, "seq": 1374, "serial_number": "HB-00014675", "timestamp":
1570995310, "type": "hub_status", "uptime": 13737}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995310, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995314, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995316, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995319, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"firmware_revision": "114", "fs": [1, 0, 15675411, 524288],
"mqtt_stats": [1, 0], "radio_stats": [5, 1, 0, 3], "reset_flags": "PIN,WDG",
"rssi": -56, "seq": 1375, "serial_number": "HB-00014675", "timestamp":
1570995320, "type": "hub_status", "uptime": 13747}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995322, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995325, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995328, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": "HB-00014675", "ob": [1570995331, 0.0, 0],
"serial_number": "SK-00017445", "type": "rapid_wind"}
raw data: {"hub_sn": &quo
[weewx-user] Installed extension and edited config, but still shows simulator
I set up a WeatherFlow station per their instructions, and it is feeding correct data to their app. I installed the weatherflowudp extension (using a Pi3), and wee_extension --list shows Version 1.03 as installed. There is a file weatherflowudp.py in /usr/share/wewx/user. I edited the /etc/weewx/weewx.conf as so: # Set to type of station hardware. There must be a corresponding stanza # in this file with a 'driver' parameter indicating the driver to be used. # station_type = Simulator station_type = WeatherFlowUDP [WeatherFlowUDP] driver = user.weatherflowudp log_raw_packets = False udp_address = # udp_address = 0.0.0.0 # udp_address = 255.255.255.255 udp_port = 50222 udp_timeout = 90 share_socket = False [[sensor_map]] outTemp = air_temperature.AR-.obs_air outHumidity = relative_humidity.AR-.obs_air pressure = station_pressure.AR-.obs_air # lightning_strikes = lightning_strike_count.AR-.obs_air # avg_distance = lightning_strike_avg_distance.AR-.obs_air outTempBatteryStatus = battery.AR-.obs_air windSpeed = wind_speed.SK-1234.rapid_wind windDir = wind_direction.SK-1234.rapid_wind # lux = illuminance.SK-1234.obs_sky UV = uv.SK-1234.obs_sky rain = rain_accumulated.SK-1234.obs_sky windBatteryStatus = battery.SK-1234.obs_sky radiation = solar_radiation.SK-1234.obs_sky # lightningYYY = distance.AR-.evt_strike # lightningZZZ = energy.AR-.evt_strike Yet when I start weewx, it still shows the simulator. The page is available at millennialhouse.mynetgear.com/weewx/ for viewing. The file at /var/log/syslog shows the weewx in listening for UDP at on port 50222, but times out. What have I neglected to do? Thanks for help. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e73539bf-5347-426f-83c0-c9e2307bd5bb%40googlegroups.com.
[weewx-user] Re: Weather station recommendations?
After reading these many good opinions and checking provided links and other leads, I've decided to buy the WeatherFlow. It was between that and the Vue. The main reported downside to the WF (rain accuracy) doesn't apply so much here in Colorado where it tends to rain a lot or not. (Today is about 4-5 inches of snow.) The main downside to the Vue seems to be the interface. I have often found serial/USB connections to be trouble and would rather work with UDP packets. Thanks again for the advice. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e5f32b02-1f97-43b6-a554-afa730dfeec6%40googlegroups.com.
[weewx-user] Weather station recommendations?
I have a spare Raspberry Pi3 to run WeeWx, but no weather station yet, and would like recommendations. Reliability and accuracy are top priorities, and I'd prefer one of the models marked as tested. I am considering a Davis Vantage Vue, but would I need to buy their pricey USB interface, or could it be interfaced another way? What other stations should I consider? Thanks for all suggestions. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/fbf1e880-bb3c-446e-a1f2-948e3840b1ff%40googlegroups.com.
