Hi Thomas, If it is any consolation I am not a programmer either, I get by Googling, trying things out, seeing how existing things work etc and am always learning new and better ways to code.
Your service is bound to the NEW_ARCHIVE_RECORD event so each time a new archive record appears your service is called and it obtains the various values from your sensor and adds them to the archive record. Since your service is in the date_services list it is called before the process_services that convert, calibrate, quality check and ultimately save the data to the database. That is all good but as you have found with only one data value being recorded per sensor per archive period the time resolution of your lows/highs for your extra sensors is your archive interval. If you want to have better resolution then you need to get more frequent values into WeeWX. If you changed your service to bind to NEW_LOOP_PACKET you could then pick up values from your extra sensors at least every 2.5 odd seconds (your station loop interval) or longer if you wanted (say every 10 or 30 seconds). The changes to your code to do this are quite trivial; however, the risk that you run with your existing code is that you may find that if a sensor is not available, your network is down or something else prevents one of more sensors being read your service may end up blocking WeeWX. When bound to NEW_ARCHIVE_RECORD you are only reading your sensors once per archive period (say 5 minutes), so if there is a delay for a few seconds while a sensor is read or it times out it likely does not matter too much. Though if you now work in a NEW_LOOP_PACKET context, where loop packets come in every 2.5 seconds, that 1 or 2 second delay can cause WeeWX to miss loop packets. This is why it is often not good practice to have WeeWX services that directly interrogate an internet address for data, it just needs a slow internet connection or a server that has disappeared and it can cause WeeWX quite a few problems. There are ways to deal with this, here are a few: 1. You can make sure that any reads you do over the network have a timeout such that if they do fail the timeout kicks in and you don't miss the next loop packet. Remember though that you are reading devices sequentially so your timeouts would be cumulative. 2. Use something like the fileparse driver (but you would need to adapt it to be a service - easily done) whereby it reads pre-formatted data from a text file. If the text file is on your network or WeeWX machine you should be safe. You then run a separate program (could be based on your existing service) that polls your sensors every so often and writes the sensor data to the file. 3. Write a service that uses a separate thread to obtain the data from your sensors and pass it back to your WeeWX service via a python queue where your service adds it to the loop packet when/if data is available. This has the advantage of interrogating your sensors in a separate thread so if there are any delays/problems reading sensors it does not bring down WeeWX. A number of drivers operate with threads as do a number of services. The forecasting service <https://github.com/weewx/weewx/wiki/forecasting> uses a number of threads as does the netatmo driver <https://github.com/matthewwall/weewx-netatmo>; basically any service or driver that obtains data from the internet probably uses threads. A threaded solution is probably the more elegant but it is also the most complex and difficult to troubleshoot, maybe you might want to consider using the fileparse approach, it would not be to difficult and would keep WeeWX from being brought down by misbehaving networks or sensors. I am sure others will have other views/suggestions. Gary On Monday, 10 September 2018 13:52:49 UTC+10, Thomas Carlin wrote: > > Hi Gary, > All that makes sense, thank you. My service is coded directly from the > documentation linked above, with the addition of a function to "somehow > downloads the data", and I have included it below. One thing to note, I am > not a programmer, I dabble as a hobby, so if there is something done poorly > or improperly, I am open to suggestions, recomendations and things that can > be done better. I have also included the relevant bit of code from > weewx.config about how I am referencing my service, and the configuration > to help explain things. Currently my service is adding data to the archive > record, and in order to augment the loop packets, I would need to change > the structure to speed up the process of getting data. Currently, with 4 > separate sensors, it takes a measurable amount of time to get the data from > all of them, and I would want to convert to a queue structure, maybe a > local MQTT instance. (I have already toyed with this idea, and this would > give me a good excuse.) Let me know if there is anything else that I can > answer or provide that would help. 2 second resolution would be great, but > I would be happy with 30 or 60 seconds. Currently, my archive interval is > set to 5 minutes. > > THank you, > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
