jiberjaber

Mines on a side that faces NE - I'm not after super accuracy, just representative of local conditions. My first screen was similar but pre-3d printer so consisted of a lot of plant saucers, spacers and long bolts

I've measured my tripod and it is set at 1.14m so the pier is another 0.2m overall higher I think...

Just measured whilst making a cuppa... 1.3m from the patio to the top of the blocks, then another 4cm or so to the base of the HEQ5 mount. It's a little bit of a reach to cap the scope in parked position. Perhaps another 10cm taller than the standard tripod? (I'll check that later when I pop down the shed... ) I went for a bit more height to give a bit more reach to the South over the roof.

I using a 'clone' that came with the tripod I am using, it is OK though not able to compare with the iOptron one. Has a few less knobs than the iOptron one; one for rotation, one for the ball itself and one for the camera clamp. Fairly new so far, so only 2 outings with it so far, time will tell if it starts to slip etc. Do the two side knobs on the iOptron one tighten against the main ball ?

My DHT22 on my dew controller is on about 2m of cable. You will need some integration time for the DHT22 plus they are not as robust as some of the other sensors (SHT30 for example) however the SHT30 is I2C so remote mounting slightly complicated.

I tried to make it the same height as the tripod was but I think I added another 100mm in the end. I'll try and remember to measure it when I take the cover off later. Each block is about 400mm from memory and the pier adaptor is circa 50mm.

Mine works on a scheduled reading and uses a rolling average for most measurements. Not sure I'd rely on the web request to trigger measurements, some sensors require some integration time for them to yield a result.

Just to add - the bottom of the pier is not finished yet.

TBF, I am surprised how mine looks with a coat of paint. During the day it is covered with a large black cover so just looks like some covered garden furniture.

Because I use the code all over my devices I have a global constant variable defined called WIFIID at the top of my code but you could just put it in the void Arduino_OTA() code directly that I posted.

It will appear in the Port settings, if you set ArduinoOTA.setHostname(WIFIID); Where: const char* WIFIID = "WXSTATION"; Then you will get a name that means sense next to the IP if you have multiple ESP devices in the lan.

Yes - as long as you remember to also include the OTA code in the new sketch

Yep - it needs an existing wifi connection to work.

Yep - no worries, that's just a version of the OTA example, the standard basicOTA is what you want... I was trying to time the capture to get the menu and hadn't noticed the cursor was highlighting the LED version (it's from teh ESP8266 version) - sorry for the confusion

I try and keep my code modular so I can reuse bits elsewhere, so I have a tab called Arduino_OTA with the following code in it:

Over-The-Air If you look in the examples you will see an example sketch which shows how you can then load you new code 'over the air' to the device. It's much quicker than USB/Serial - means unless you have a really big problem, you can update the device remotely as long as it's on the local network.

One of the first things I do now is ensure I have OTA coded - not that I have any buttons to press with the ones I use, but it is quicker to get the code on teh device with OTA programming.

I'm not sure which ESP32 you are using but you may have to press a button when powering up to put set the boot mode to be able to programme it. (I think your ESP8266 board had a programme button and reset button on it?)

1.8.10 is where I'm at too. I have had issues in teh past where I've had to rewrite code after Arduino updates so I don't make the jump now unless I really have to!

That's not too different to my setup, wind speed & direction over a flat 5 core cable plus rain bucket (bell/speaker cable) is on a scaffold pole and the ESP plus temperature and humidity in my Stephenson screen about same distance away. I did consider i2c over a longer distance but I found it not that reliable once over 20 cm or so though with some passive components I suspect you could extend that.

You might have already mentioned but I may have forgotten.... Is the reason for not using one device because of availability of IO pins ? I think when I did mine I worked through the sensors individually to prove them working then tried to make the code modular for each sensor and then added them all together, after that it just grew as I added bits on or swapped out sensors... there's always that journey when a sensor you thought was right can't survive the environment! LOL

Looks like ESP-NOW is still Wifi but without the connection stuff to an access point, here's some more code and info for reference Gina.. https://github.com/HarringayMakerSpace/ESP-Now

Looks like ESP-NOW would be fun to look at but not necessarily the easiest solution - I'm not sure you will be able to serve your web page over it, I'd probably get it all working over wifi initially as there is plenty of reference code out there already to get you up and running with a proof of concept. I'll going to look into ESP-NOW a bit more but I haven't seen anything about how it plays with Wifi and Bluetooth in the mix also as it seems to be using the same spectrum but might be employing a different way transmission.

My experience with the ESP8266 was the web service and dealing with interrupts for the wind and rain didn't mix. Might be OK with the '32 but this is why I went for MQTT