On Tuesday, 26 September 2017 17:56:54 UTC-3, Christian Peters wrote:
>
> To discover the „TIME:0“ and the missing entry in the label map „TIME = 
> dateTime“ took some time and help from this forum! Thanks!
>

The current version of the driver actually creates a time value if zero is 
passed in. I am doing this because the field station does not have a 
reliable clock. So I provide zero as the value, and the driver uses the 
time on the weewx host:
                    if( key=="TIME" and data[key] == "0"):
                        data[key] = str(int(time.time()))

mosquitto_sub -h 192.168.2.143 -v -t weather/#
>
> regarding connection, losing connection, reconnection…
> Grabbing values with this command works flawless.
>
> But with this setup I see that your weewx loses connection after a while. 
> The question is why there is a timeout?? 
> How to avoid this timeout? 
>
 
If by "timeout" you mean 

>
> Sep 25 21:44:44 debian weewx[4084]: wxMesh: Sleeping for 1
>

it does that to avoid hitting the MQTT broker too frequently.
 

mosquitto log:
>
> 1506377517: Client mosqsub/4185-debian has exceeded timeout, disconnecting.
> 1506377517: Socket error on client mosqsub/4185-debian, disconnecting.
> 1506377520: New connection from 192.168.2.153 on port 1883. (reconnection 
> only with wxMQTT)
>
> As you described your driver doesn’t reconnect. Maybe it’s a problem of 
> the network between the VM and the BananaPi, maybe I should switch from the 
> VM test setup to the system I will run. Then I first have to enable running 
> a second instance of weewx. As it is my productive system with some other 
> tasks running I have to take care! :-D
>

Likewise, I am stuck on an old version of weewx for the same reason. 
 

>
> Your driver would fulfill my needs perfekt as I will grab some additional 
> sensors located in the garden. Tom wrote it then would be possible to query 
> this second database of the second weewx from my „main“ weewx instance and 
> include the sensors in the website and plots from my VPII. 
>
> But as I described: even with the modified wxMQTT driver which reconnects 
> the debug of weewx doesn’t show that data is coming in again into weewx. So 
> something doesn’t work after reconnection to the broker. 
>
> weewx log after disconnection…no more log entries….:
>
> .....
> Sep 25 21:53:18 debian weewx[4211]: wxMesh: dateTime 1506369199
> Sep 25 21:53:18 debian weewx[4211]: wxMesh: packet content: barometer =  
> 1013
> Sep 25 21:53:18 debian weewx[4211]: wxMesh: packet content: Temp =  21
>
> I will check again tomorrow and try to setup  a weewx instance on a Raspi 
> (not the VM) and will see whether it changes something (no disconnects?).  
>
> If I will reach a reliable setup I will grab the sensor data send by an 
> Arduino per serial print (USB connection to the BananaPI) and will publish 
> this sensor values to the broker. As there is a geiger counter connected 
> too straight to the BananaPI per USB which emmitts values to I have 
> different values at different intervals I feed to the broker and hope weewx 
> will put them all together into loop packets.
>
> How often does your sensors publish values to the broker?
>

The indoor station publishes  every 10 seconds. The outdoor station 
publishes every 30 seconds currently. I might decrease the frequency to 
give longer batter life.

I wonder if you are not publishing frequently enough? If the weewx 
subscriber has nothing to receive, it might get disconnected by mosquitto.

In the gateway which receives data from the outdoor station via 2.4GHz 
radio and publishes on my LAN as MQTT, I set this:

..
  conn_opts.keepAliveInterval = 300;
...

so the client up to 300 seconds to publish, before it will be disconnected.

There's a good description of the different methods to look for new 
publications here:
http://www.steves-internet-guide.com/loop-python-mqtt-client/

I use loop() which has to be called regularly, Frederic switched to using 
loop_start() which polls on its own and will reconnect if it gets dropped. 
I couldn't figure out how to get data between the separate thread which 
loop start spins up. 

Reply via email to