Gina

I'll change to the RPi 3B then and Ethernet. The IP address will be different so means changing the broker IP in all the clients though - slight nuisance. I'll leave it until tomorrow.

No problem with developing the sensor sketches - they are coming on nicely. My main concern is displaying the dashboard. It keeps losing the connection. The RPi is only about a metre from the WiFi AP. Maybe the WiFi on the RPi Zero W is poor. Wondering if I would be better off with an RPi 3B which has Ethernet and to use a wired connection rather than WiFi. Opinions most welcome.

Had to take the anemometer apart because the pivot had come loose. Replaced the nut with a Nylock - it won't come loose again! One of the magnets came out so I'm running on one magnet. I'll rebalance it later if needed. It will need 4.4s Interval to to give mph from the pulse count. I don't think using 4.4s instead for the Gust period rather than 3s will matter much - it won't be going towards an official weather report!

Beaufort Scale. Analysis of calibration results from cup and propeller anemometers.

Strange things still happening with the dashboard display. Every so often it disappears altogether, sometimes some or all of the widgets disappear, sometimes these only show the last few seconds or minutes and most of the time shows everything correctly with full histories. I have the Pressure History set to 4 days and data has been retained in the RPi since it was last powered up yesterday (Friday) at about 10am, so it's been holding data for over 24 hours now. The RPi is being powered by a Raspberry PSU plugged into the UPS system so power has been on continuously. Seems the data is being held in the RPi and disconnecting sensors makes no difference except that no data is logged while they're off. Nor does disconnecting the RPi from the Mint box. So data must be held by either the broker, Node-RED or Dashboard.

I have the wind speed sensor working with test setup on the living room table.

Been looking at the Met Office definitions of Mean and Gust speeds:- With Gust being wind speed in a 3s period, this seems to be what I should use as the Interval. If I were to use a 10m period for the Mean wind speed, I think I would like a rolling average so that it doesn't produce big changes in the displayed Mean Wind Speed. Looks like the wind ESP32 will be doing quite a lot of work, processing all this data but it does seem to be a fast processor. We shall see!

Gone back to my calculations of the relationship of wind speed to pps from the Hall sensor. With 4 magnets it worked out at a little under 1mph per pps, so with 2 magnets it's mph for counts in a 2s period. Actually, the figure has come out as 2.3. If I use 4.6s as the interval between readings I can divide by 2 for mph. I thought of using just one magnet but that would unbalance the anemometer, though admittedly with those small magnets close to the axis, maybe not much. Alternatively, maybe a 2.3s interval would be alright and would simplify the calculations. It doesn't necessarily mean that messages are sent at that rate. I'm reluctant to send messages over MQTT too often but I may be over cautious..

Latest dashboard display. Hoping to get the wind speed working today, though this is only the speed sampled every 4 seconds. From this, mean and gust speeds will be calculated in a later sketch.

I think this might work. (Password removed,) /********* Rui Santos Complete project details at https://randomnerdtutorials.com ******** Modified and added to by Gina 2020-08-21 ******** */ const int intervalSeconds = 4; // Set sampling interval in seconds // Set GPIO for Hall Sensor const int HallSensorPin = 27; int PulseCount = 0; #include <WiFi.h> #include <PubSubClient.h> #include <Wire.h> // Replace the next variables with your SSID/Password combination const char* ssid = "Ubiquity"; const char* password = "--------"; const char* mqtt_server = "192.168.1.250"; WiFiClient windClient; PubSubClient client(windClient); long lastMsg = 0; char msg[50]; int value = 0; // Checks if Hall sensor was triggered void IRAM_ATTR HallTriggered() { // Serial.println("Hall Triggered"); ++PulseCount; // Increment count } void setup() { Serial.begin(115200); setup_wifi(); client.setServer(mqtt_server, 1883); client.setCallback(callback); // Hall Sensor mode INPUT_PULLUP pinMode(HallSensorPin, INPUT_PULLUP); // Set HallSensor pin as interrupt, assign interrupt function and set FALLING mode attachInterrupt(digitalPinToInterrupt(HallSensorPin), HallTriggered, FALLING); } void setup_wifi() { delay(10); // We start by connecting to a WiFi network Serial.println(); Serial.print("Connecting to "); Serial.println(ssid); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println(""); Serial.println("WiFi connected"); Serial.println("IP address: "); Serial.println(WiFi.localIP()); } void callback(char* topic, byte* message, unsigned int length) { Serial.print("Message arrived on topic: "); Serial.print(topic); Serial.print(". Message: "); String messageTemp; for (int i = 0; i < length; i++) { Serial.print((char)message[i]); messageTemp += (char)message[i]; } Serial.println(); // Feel free to add more if statements to control more GPIOs with MQTT } void reconnect() { // Loop until we're reconnected while (!client.connected()) { Serial.print("Attempting MQTT connection..."); // Attempt to connect if (client.connect("windClient")) { Serial.println("connected"); // Subscribe // client.subscribe("esp32/output"); // client.subscribe("esp32/roof"); } else { Serial.print("failed, rc="); Serial.print(client.state()); Serial.println(" try again in 5 seconds"); // Wait 5 seconds before retrying delay(5000); } } } void loop() { if (!client.connected()) { reconnect(); } client.loop(); long now = millis(); if(now - lastMsg > (intervalSeconds*1000)) { Serial.println("PulseCount :- "); lastMsg = now; // Convert the value to a char array char countString[8]; dtostrf(PulseCount, 1, 0, countString); Serial.print("Count: "); Serial.println(countString); client.publish("wind/speed", countString); PulseCount = 0; } }

Hall sensor datasheet

This is the code for the Hall sensor interrupt setup with Serial Monitor for testing.. /********* Rui Santos Complete project details at https://randomnerdtutorials.com ******** * Modifued by Gina for Wind Sensors */ const int intervalSeconds = 4; // Set sampling interval in seconds // Set GPIO for Hall Sensor const int HallSensorPin = 27; int PulseCount = 0; // Timer: Auxiliary variables unsigned long now = millis(); unsigned long lastMsg = millis(); // Checks if Hall sensor was triggered void IRAM_ATTR HallTriggered() { // Serial.println("Hall Triggered"); ++PulseCount; // Increment count } void setup() { // Serial port for debugging purposes Serial.begin(115200); // Hall Sensor mode INPUT_PULLUP pinMode(HallSensorPin, INPUT_PULLUP); // Set HallSensor pin as interrupt, assign interrupt function and set FALLING mode attachInterrupt(digitalPinToInterrupt(HallSensorPin), HallTriggered, FALLING); } void loop() { // Current time now = millis(); // if(now - lastMsg > (intervalSeconds*1000)) { Serial.println("PulseCount :- "); PulseCount = 0; lastMsg = now; } }

While the Button sketch is fairly close to the operation I want it's not right but that and another example using a PIR device to cause an interrupt have given me the information I need. The Hall sensor will trigger an interrupt and the ISR will count the pulses. In the Loop I will time the period using millis as with the other MQTT sketches. This will produce a timing loop which will take the count and send it to the broker then reset the count.

I'm now looking at the wind sensors unit. Anemometer and wind vane. The anemometer has a Hall device which has an open collector output and Schmitt trigger incorporated so the o/p is digital. This would look the same as a button to the ESP32. The rotating part has two magnets giving 2 pulses per revolution. I've worked out that this would give one pulse per mph with a 2s counting time. The usual sampling period for the other sensors is 5s so I might go for 4s period rather than 2s. Anyway, I can decide that later. The signal from the Hall sensor will trigger an interrupt to count pulses while the time in between will read the wind vane and do some calculations for wind direction. This is a sketch I have found for ESP32 interrupt processing. struct Button { const uint8_t PIN; uint32_t numberKeyPresses; bool pressed; }; Button button1 = {18, 0, false}; void IRAM_ATTR isr() { button1.numberKeyPresses += 1; button1.pressed = true; } void setup() { Serial.begin(115200); pinMode(button1.PIN, INPUT_PULLUP); attachInterrupt(button1.PIN, isr, FALLING); } void loop() { if (button1.pressed) { Serial.printf("Button 1 has been pressed %u times\n", button1.numberKeyPresses); button1.pressed = false; } //Detach Interrupt after 1 Minute static uint32_t lastMillis = 0; if (millis() - lastMillis > 60000) { lastMillis = millis(); detachInterrupt(button1.PIN); Serial.println("Interrupt Detached!"); } } I doubt there would be any reason to detach the interrupt in my case. Instead there would be procedures called every so often from the void loop to process the count and the wind direction. This code will be integrated into the MQTT sketch. The button.pressed state will need moving to the ISR I think. I'll think about that.

Changed the tab order in the dashboard allowing me to re-deploy and the histories are back. This points to Node-RED as the culprit.

Just looked at the dashboard and something has happened. Had to restart MQTT Explorer as that just showed an empty window. Now it's just showing data since I started it.

Yes, I'm hoping to. I have an Arduino which was set up for data logging on an SD card, some years ago. Maybe I can connect that into my MQTT network. OTOH I don't know if I still have the sketch I used. I don't think there's any way of recovering the sketch from the Arduino as the code is compiled before uploading. May be quicker/easier to just start anew. The data was stored as a text file with one line per data point.

Left it running overnight and all fine.

Interestingly, all the temperature histories have gone but the pressure history has come back completely from when I set up this morning. All the histories gone from the Dashboard are still showing in the MQTT Explorer, so It seems to me that the problem is in the Dashboard display or Node-RED.

I think I would prefer to keep a database on a separate unit from any of the sensor modules and read that for the history as in a "proper" weather station.

MQTT Explorer history doesn't go as far back. Is there any way of getting more history in MQTT Explorer?

Just happened again and this time all histories reset to 18:30. If I can't stop this happening the histories will often be useless. In actual fact only the atmospheric pressure trend really means anything. Maybe a better idea is to store older values in the ESP32 and compare with current reading to determine the trend and display that as a Gauge.

If so I don't know how.

I'm still getting some strange effects which I don't understand. For instance, in the History graphs, instead of getting the full history from when the device was started, it sometimes gets cut short sometimes the same minute at start and finish. Then gradually the time covered increases. This is not global, I mean not all graphs are affected in the same way. Also, it only happens occasionally.