Developing my weather station, Work in Progress
As far as the UV sensors are concerned one has to be aware that acrylic covers and normal glass block UV light rather effectively.
Had something similar happening to me with always a 0 from those sensors since they have to be kind of fully exposed to the light of the sun without nothing interfering...
The tipping bucket has still an issue. The summing over time by eGeoffrey does not work for this application.
Still tracked with https://github.com/egeoffrey/egeoffrey-controller/issues/23. Could take a while to implement it though.
Egeoffrey is not able to deal with data from a "tipping bucket" properly at the moment. The accumulation of the data of the bucket has to be done by the weather station.
The ticks have to be counted per hour. Each hour the amount of the preceding hour is sent. Next to that amount the sum of the figures of the preceding 24 hours is transmitted.
To create a real link between the gathered rain information and the time the rain was falling, the weather station needs a more or less accurate clock. It is possible to run a clock on the weather station which provides time information that is accurate enough. The only thing required from the outside world is a sync signal.
My modules communicate via MQTT. The most flexible way to implement a time sync signal is distributing time via MQTT. One single broker is used at my place.
One time sync module is implemented. It is not incorporated into the mesh. This module synchs its own clock via the NTP protocol with an internet time-server. It sends time to Mosquitto in a readable format with a ten seconds interval. (year, month, day, hour, minute, second) Mosquitto distributes the time message at the same pace. Time is sent with topic: "in/decoder ID/time".
Any other module using a clock does sync time during booting. After this first sync, time can be updated as required by the application.
The time decoder is displaying the time using an TFT screen.
This option is implemented.
The first one is an alarm clock. The function of the earlier developed data display and system control module can be taken over.
The TFT screen used now is larger than the one from the data display module.
Instead of a data retrieval system a broadcasting one is implemented. The commands to control the system are given with a TV remote control.
Re-designed are the display screens, the data exchange and the control.
Two pages are foreseen. The first one for time and weather information and the second one for alarm system information.
Default the time page is displayed. When an alarm occurs the alarm page is displayed on reception of the alarm data. Next to this automatic pop-up the alarm page can be activated with the remote control.
Data are broadcasted by eGeoffrey. Data are broadcasted after processing newly received data. A topic structure needs to be designed. Data are received and stored by the module. Depending on the active page data are displayed and refreshed at regular intervals.
Commands are given with a TV IR-remote control. The commands are received by the module directly without data exchange via MQTT.
Control is as easy as possible. Mainly the number pad is used. A command starts with the "red" key and ends with the "yellow" key. The command given is executed with the "green" key.
When on the remote a key is available with a function allocated which can be used for control of my system, it is used.
Remote control functions:
setting and silencing the alarm clock
switching display pages
control the alarm system
Ok, I see this tipping bucket issue to be something I'd rather need to re-prioritize high despite you have found out a brillant solution IMHO. Try giving me some hit regarding the expected behaviour on https://github.com/egeoffrey/egeoffrey-controller/issues/23 and I'll see if I can work on it ASAP. I expect this to be something like measures get in as usual and at any time, hourly aggregates are the sum of those values per hour, daily aggregates are the sum of the hourly measures. Is it the case?
Regarding instead your approach, why not using a RTC module and every here there your station ask for a time sync to re-align the RTC if needed? Thanks
The software clock of the ESP8266 is rather stable (deviation seems to be a second in several hours). For that reason I do not need an RTC module.
In the mesh I can only deal with MQTT messages. UDP is not supported.
Therfore I have to send a sync signal via MQTT.
Once this is implemented it is a general feature for my system.
Your perception of the tipping bucket problem is OK.
I will put a remark in the issue.
The integration of the IR remote is done.
Arrow left and arrow right select the page to display.
Volume+ and Volume- toggle the alarm clock on/off.
Ch+ and Ch- toggle snoozing.
"Red" , four numbers, "Yellow", "Green" sets the clock alarm time.
A piezo buzzer is used to produce the alarm clock sound.
Next challenge is the data exchange.
Great piece of work as usual
Even if you have already found a workaround, would be great if can give the latest version of egeoffrey-controller a try, even if in a test environment, just to confirm the implementation of the tipping bucket is meeting the requirements. Thanks!
I will do the test when I finished my solution.
I will report back on it.
The software modules are ready. The next step is putting the hardware together. Then the software integration can be finished.
Quite a storm hit our country.
My weather station is torn apart completely.
That is the end of the project.
Quite a storm hit our country.
Really sorry to hear that Hope apart from the weather station you are safe!
I really wanted to thank you once again for keeping up this thread constantly updating about your progresses. Absolutely impressive what you have built in such a short time!
Thanks again for the contribution