Arduino Arsing About

My request to the Sonoff-Tasmota Github issue forum elicited a number of replies, most significantly from the main man, Theo Arends. In short, he's suggested that I submit a modified version, incorporating the latest SHTC3 sensor changes, that supports multiple sensors on the various addresses. I've done this, mentioned it on the forum and I'm now waiting to see what happens. Modelled on the DHT sensor code, it now Uses an array of struct SENSORINFO to hold individual sensor details On a Show request, loops, reading sensors in turn and loading the data into a new JSON object each time, rather than a sensor data array with Address also included Sensor names include the address value in hex, much like before It's much simpler code like this, and given the effort I'd already put in, didn't take long to knock out. Let's see what happens...

I have a hankering to measure the input and output temperatures of my condensing boiler, in order to determine if it's likely to be actually condensing at any time. I have lots of SHT30 sensors, which attach handily to NodeMCU units. However, running 2 separate rigs, one each for input and output, means that temperature measurements will not be synchronised, which doesn't account for the action of the boiler and its heat output rate of change. It appears that the SHT30 has two I2C addresses (0x44 and 0x45), which are available on the Wemos D1 knock-offs that I have. So I started out by modifying one to use a different bus from the standard one - this is easily done by bridging a link with solder. I then used 2 NodeMCUs running together to check that the newly addressed device is actually detected and works. It does. Pair of NodeMCU/SHT30 setups in action Close-up of SHT30 devices -RH(44) has soldered address link (circled) So, let's see what we can do, eh? I

I purchased some Hall Effect sensors (Honeywell SM353LT) and some neodymium magnets to have a look at motion detection for the rain gauge. I should have realised from the "SM" that these are Surface Mount devices. They are also incredibly small!! 2 SM353LT HE sensors in a travel pack! You can just see the connectors in the pack - 4 on the lower side of the package. Fingertip shows the scale, tiny. Now to see if I can connect these to anything. How? I have some one-sided copper PCB, some 0.1" pins, a soldering iron and various cutting implements. Go to it, Mr. G! Board with holes for pins, and pins Board, pins, device placed for working out location etc. Board with traces cut - I've made it simple, centre pin to centre contact! Truly horrible pic of device ineptly soldered on Finished effort - doesn't look too bad! So all I have to do now is power it up and tickle it with some magnets. Wish me luck! Simple micro:bit code A

My 8 year old (nearly 9, g-dad!!) grandson has a school homework project to build a rain gauge. It occurred to me that it might be fun to build a properly useful one that would measure rainfall continuously and actually enable the recording of said measurements in a sensible machine-readable manner. How would you do that?? DuckDuckGo is my new friend, since Google appears to have taken a walk this afternoon... Some ideas occurred to me, independently of research: Weigh/sample the amount of rain falling on an area over a period of time Measure the height of water in a known area tube Optically (interruption of light beam) Mechanically (float etc., potentiometer?) Audibly, level of noise on surface  Needless to say, all of these are used! 3) is tricky to calibrate I should imagine, not least because it requires a known amount of rain to fall. I don't know if using a hose with shower attachment would count - rain has differing drop sizes and fall heights, not to mention

I've finally worked out how to load the Tasmota code into NodeMCU devices, or probably any other for that matter - sadly, I had to re-do it before I realised what I'd done the first few times, which was actually follow the instructions! >Sigh< . Anyway, I really like mDNS, the multicast DNS mechanism whereby service providers advertise their services using multicast. This is an ideal mechanism for local services on one's own home network, and is a part of Apple's OS X and iOS, Linux distros, and (even!) Windoze. Sadly not Android. Tools. It was known as Bonjour, and is more usually known as Avahi in the Linux world. Basically, you use a DNS name of the form " yourhost.local ", where " local " triggers the special magic, and your application finds the service without needing to know the IP address. Pretty much like standard DNS eh? Except it's a completely separate code base and specific applications or OSes have to make separate calls to