Sensing mains switching with Arduino

[PeterW]

Right ... on top of a couple of other little projects, I’m building up my knowledge of how certain systems are operating. 

 

One thing I want to do is sense the on/off and state of a couple of valves and pumps, but that gets me into some questions. 

 

1 - the 3 way valve has a microswitch, is there any issue in running 5v/GND through this directly...? Only query would be that the   connections would be inside a wiring centre containing 230v

 

2 - would the quickest way to sense the pump running (ideally a logic 1/0 switch) to be to put an SSR in parallel with the pump..?

 

Some of this may be a distance away from the Arduino so using I2C connected sensors is probably not an option. 

 

Thoughts..?

[Jeremy Harris]

As long as you adequately separate and insulate the 5V connections from the 230 VAC ones, then there's no problem - take a look at a typical ASHP connection strip as an example - you'll often find 12/24VDC dry contact connections as well as 230 VAC connections in reasonably close proximity.  If it were me, then I'd try and make up some plastic shields to cover the 230 VAC connections just as belt and braces, but inside equipment it isn't required by the LV Directive to do this.

 

I'd sense the pump using a flow switch in the pipe, as that's fail safe and provides isolation.  A suitable one for low voltage use would be one of these: https://cpc.farnell.com/gentech-international/fs-02/flow-switch-300v-0-5amps/dp/SN35507

 

(Don't get the FS-01 as that uses an internal SSR, despite what the docs say about having a reed switch, so doesn't work at 5 VDC)

[Ed Davies]

How about a couple of small mains powered relays in a separate small box adjacent to the wiring centre? Run 5 (or 3.3) V or even 1-wire or the like through those.

 

E.g., https://www.amazon.co.uk/Socket-AC220V-Voltage-Electromagnetic-Relay/dp/B00K82ZDR0

[PeterW]

Thanks both. 

 

Considering a relay thanks @Ed Davies and have now decided I may use this elsewhere too ..! Just annoyed I ran Cat5 everywhere but to where I want to sense now ..!

[MikeSharp01]

Isolation very important so solid state Opto isolators all the way on this one, mechanical relays are all well and good but small high (ish) frequency signals don't make it through very well and shorten the contact life. THIS chip does it as long as you are careful on the board to keep isolation distances, 4K Volts plus isolation if you do, and with a few surrounding components to: a. diode to prevent reverse biased over voltage on the internal LED during the bottom half of the ac cycle, b. a suitable resistor to keep the current across the LED low and c. a capacitor across the output to smooth out the 50% of cycle of the incoming mains (don't suggest doing this on the input side -  much safer on the output). The choice of value for the cap will need some thought as it will slow down the off response time by a few, perhaps 10s of, milliseconds.

[PeterW]

Thanks @MikeSharp01 - this will be pretty low frequency stuff that has long time constants - it’s about monitoring the state of pumps and valves that aren’t changing with high frequency. 

[ProDave]

59 minutes ago, PeterW said:

Thanks @MikeSharp01 - this will be pretty low frequency stuff that has long time constants - it’s about monitoring the state of pumps and valves that aren’t changing with high frequency. 

Make sure you filter and debounce what it intended to be a low frequency on / off input. You may have read my thread about my LG heat pump that was spuriously tripping. I eventually found it was picking up noise on the room thermostat input, something that is supposed to monitor an low frequency on / off switch. But instead the input was way too sensitive and responded to short duration induced noise spikes.  I had to add my own filtering, something you would think someone like LG would have known to do.

[MikeSharp01]

1 hour ago, PeterW said:

Just annoyed I ran Cat5 everywhere but to where I want to sense now ..!

Jump on the @TerryE wmos D1 miniPro solution then you can just echo the readings across your wifi or even set up a dedicated network of the little buggers, no wiring required even make a daughter board for the optos - but mind the isolation issue!

[MikeSharp01]

5 minutes ago, ProDave said:

I had to add my own filtering, something you would think someone like LG would have known to do.

In software or hardware?

[ProDave]

15 minutes ago, MikeSharp01 said:

In software or hardware?

I did hardware filtering on the heat pump. But if I were building it I would do both. i.e don't act on an input until it has been on continuously for a certain period of time.

[Ed Davies]

I'd very much like to do the same sort of thing as I think @PeterW wants to do but in a rented house it's not really sensible to fiddle with the mains wiring so I'll probably just put some temperature sensors on the flow and return pipes.

 

It's an oil boiler with fairly conventional S-plan wiring. I'm currently logging various room temperatures and humidities, etc, and have a 1-wire sensor stuffed up the radiator in the room I use as my study. All feed into an MQTT server running on a Raspberry Pi which puts all the data in a Sqlite database. To get a finer-grained view of the what the heating is doing I'd add two mains-powered relays in parallel with the motors for the CH and DHW valves and look at the output with something. Something could be an Arduino (I have a few of various sorts) but actually I'd likely use an ESP32 (haven't played with these yet but read a bit about them) or say sod it and just use a Pi Zero-W. Whatever - something with Wi-Fi which can talk directly to my MQTT server would be least hassle.

 

“Filtering” would consist of only sampling the relay outputs every few seconds, sending an MQTT report if they've changed or once every minute or two if not.

[TerryE]

My control system runs on an RPi directly connected to a couple of ESP8266s that drive my pumps and heaters using SSRs.   I've got DD18B20s all over my pipework.  I use an SSRs to turn the pump.  I don't bother with a flow switch.  Why bother?  I just take the temperature at each zone just before and after it enters and leaves the slab.  If the pump is running and the water into the slab isn't heating as expected then something is wrong.  

 

PS.   Ed,  I suggest that you stick an SSD on your RPi (or buy one of the clones such as the Odroid C2 which as 2Gb RAM and an eMMC slot) and stick to MySQL/MarianDB ?

 

[MikeSharp01]

8 hours ago, TerryE said:

My control system runs on an RPi directly connected to a couple of ESP8266s that drive my pumps and heaters using SSRs.   I've got DD18B20s all over my pipework.  I use an SSRs to turn the pump.  I don't bother with a flow switch.  Why bother?  I just take the temperature at each zone just before and after it enters and leaves the slab.  If the pump is running and the water into the slab isn't heating as expected then something is wrong.

A few of us will know all these part numbers but for the rest:

 

ESP8266 = a micro controller with loads of IO such as embodied on the 'WEMOS' D1 board.

SSR = Solid State Relays.

DS18B20 (not DD) = Semi intelligent Temperature sensor.

SSD = Solid State Disk (give your RPi - Rasberry Pi, some local storage.)

 

Have I got that about right @TerryE

[Ed Davies]

My original logging was purely to text files. I tried both MySQL and MongoDB. Gave up on MySQL pretty quickly as it was such a clunky old-fashioned bit of nonsense - e.g., text not being Unicode by default, hassles with passwords and stuff. MongoDB was OK but depending on the indexing the query performance was very poor for either lots of recent data or sparse long-term data. Sqlite has been working fine for me on an SD card with, currently, 1.7 GB of data since 2016-11. If, as a result, the SD card dies every two years or so that's probably acceptable. Still, I'm thinking of going back to text file logging though with a slightly different architecture from my previous version mainly so I can back up the database to my laptop more automatically and continuously. Yes, MySQL would probably allow that but with a lot of faff, no doubt.

[Ed Davies]

2 minutes ago, MikeSharp01 said:

Have I got that about right

 

Yes. Would add though:

 

3 minutes ago, MikeSharp01 said:

ESP8266 = a micro controller with loads of IO such as embodied on the 'WEMOS' D1 board.

 

The key thing these have over, say, an Arduino is the built-in ability to do Wi-Fi. In fact, they're more like Wi-Fi chips that happen to have some spare processing capacity to do other things. The more modern replacement is the ESP32 which has a few nice but not completely compelling advantages. But if you're starting from scratch you might as well use the ESP32.

[TerryE]

4 hours ago, Ed Davies said:

 if you're starting from scratch you might as well use the ESP32.

 

Yes, the ESP32 is a very nice device and a very good successor to the ESP8266.  However the challenge with all of these devices is that the developer platforms are all community driven.  There just isn't the commercial  model to pay for funded environment development, and hence you pretty much have to work in C.  I am one of  the NodeMCU Lua developers.  Espressif sent me some pre-release ESP32 samples about two years ago, but they've only become available to the general buyer at a reasonable price and delivery in the last 6 months or so.   I and the other collaborators haven't time yet to port the firmware and all of the supported device libraries to the ESP32  

 

4 hours ago, Ed Davies said:

In fact, they're more like Wi-Fi chips that happen to have some spare processing capacity to do other things

 

I feel that is a bit of an uninformed view.  You can now happily run a 5,000 line Lua application on one and control all of the I/O for a Home heating system (in my case 4 SSRs, 20 thermometers, 2 flow meters) on one.  That's a little more than being a "Wifi chip".

 

As to using SD cards, as you say they fail and regularly.  And that is a total PITA.  The nub of the issue is that the EXT4 file system really assumes that there is a decent wear-leveling flash controller between the processor and the flash memory chips themselves.  Yes the Linux kernel does have some flash support but this is really to talk to the flash controller with garbage collection hints.  This just isn't the case and like all file systems or pretty bare flash devices like your typical microSD card, you will hit the erase limit on hot sectors and the device will fail.  That's why you need an SSD or a board that supports eMMC.

 

5 hours ago, Ed Davies said:

Gave up on MySQL pretty quickly as it was such a clunky old-fashioned bit of nonsense - e.g., text not being Unicode by default, hassles with passwords and stuff

 

?? "create database ed character set utf8;" and most DB installs nowadays have utf8 as the default character set, so you don't need the last three words.  Not that hard.  I also agree that security can be a PITA, but it is less of a pain in the arse than the alternative.

[Jeremy Harris]

My problem is that I'm really a hardware person who happens to have had to do a bit of coding, so I approached monitoring our house from a hardware-driven perspective.  I have several PICs all forming part of a wired network that gets real time from a GPS module, runs a RTC as a backup that's regularly updated by the GPS (every hour, which is total over-kill), collects data from a load of DS18B20's around the house, and outside, plus a couple of RH sensors and an NDIR CO₂ sensor in the house and stores the data every 6 minutes to a USB stick, in .CSV text files that have file names in the format "month_year". 

 

Hanging off this is a four line LCD display in the hall that displays date, time (automatically corrected for BST), day of the week and some temperature, RH and CO₂ data (handy to see how cold it is outside more than anything else, and for setting clocks around the house).  All the data is transmitted slowly (2400 baud) over Cat6 cable, that's also used for power and connecting all the sensors.  The whole lot is daisy chained, so one PIC acts as a data hub for all the sensors, sampling them as fast as it can (the limit's the DS18B20 12 bit conversion time) converting the sensor data into calibrated ASCII values, another two run the clock system (one for the RTC backup, one for the GPS) and transmits both time data and a "store a sample now" command every six minutes (starting on the hour), one just collates all the incoming date, time and measured data and sends a text line to the open file on the USB stick to store data on command.   

 

The model for adopting this distributed processing topology was my car, which uses loads of processors scattered around the car, with each dedicated to just an easily testable function.  As someone who's not inherently at home writing loads of code, this method allowed me to develop each functional block and test it thoroughly on it's own, by just having a well defined I/O spec for that particular functional block. 

 

I won't pretend it's elegant, and it does suffer from the fact that it's not integrated into house LAN, but is entirely stand alone.  This is a nuisance, as it means I have to turn it off to swap USB sticks over to get at the data.  I like keeping the data on a USB stick, but one thing I want to do at some time is also send the data to the LAN, so I can have some form of simple web interface running on the RPi3 file server, perhaps, that allows me to pull off data at any time, without needing to go and get it off the USB stick. 

 

My problem is finding the time to be able to sit down and get to grips with doing this - I'm finding it harder to learn new stuff as I get older, and it takes me longer to pick things up than it used to.  Whilst clearing junk from the old house out I came across a floppy disc and a fan fold paper print out of some Fortran 77 source code that I'd written back in the 1980s.  It took me about half an hour to work out how the code worked, and it wasn't that complex, just a 3D trajectory prediction programme, that calculated an air launched weapon water entry point, with a known release point, height, airspeed, track, wind speed and direction and weapon ballistic data, and adding a correction for Coriolis effect.  I remember re-writing that bit of code to run on a Psion, using OPL, at some point, so I must have been pretty familiar with it once, but I stared at it for ages before understanding how I'd done it all those years ago.

[MikeSharp01]

9 minutes ago, JSHarris said:

I won't pretend it's elegant, and it does suffer from the fact that it's not integrated into house LAN, but is entirely stand alone.

It works though doesn't it. The weakness, as you have said before, is that it relies a bit too much on you being there to sort it out. What we need is to throw out there an open source home automation protocol (hardware / software / whatever) that we can all develop to and that then forms a community of practice that others can latch (pardon the pun) onto so when those of us who have bespoke systems pass into the land of limitless energy (I assume) where the laws of physics don't apply can be confident that those left behind us won't have to rip it all out and start again as soon a it goes phutt. 

[Dreadnaught]

I am I suspect an unworthy interloper into boffins' corner. I have been following many of these discussions with a keen interest. Currently, each of your posts requires me to look up many things online. My history of programming started as a youngster but was curtailed quite early by a career change. I am keen to learn more, to monitor things and to automate things. I am learning by watching. Anything here that help someone like me is welcome.

 

I use the Apple ecosystem so Apple Homekit is of particular interest although I don't think I have seen it mentioned here.

 

I am also interested in the new Bluetooth mesh protocol for lighting control. I wonder if it will disrupt the lighting-design industry.

Edited September 3, 2018 by Dreadnaught

[MikeSharp01]

2 hours ago, Dreadnaught said:

mesh

IMV meshes are the future as they take the resilience concept underpinning the Internet and make it scalable in micro environments like houses and even cars.  They are inherently simpler from a users point of view although rather more demanding in designing for reliability. I wonder if the problem revolves around investment (in previous schema) challenging change. 

[PeterW]

@JSHarris I’m in your camp here ..!! Whilst I like the rPi, the thing I hate most is that if there is any power loss then I’ve got the potential for corrupt data whereas the Arduino just reboots itself and carries on...

 

I’ve even rehashed the design on the IVT controller today dispensing with the thermistors and going 1-wire as I’ve got a load of them lying around the place ...! 

 

Out of interest, how did you mount the 4x20 display ..? I’m thinking a 2G faceplate with a CNC hole is the easiest. 

[Jeremy Harris]

14 minutes ago, PeterW said:

@JSHarris I’m in your camp here ..!! Whilst I like the rPi, the thing I hate most is that if there is any power loss then I’ve got the potential for corrupt data whereas the Arduino just reboots itself and carries on...

 

I’ve even rehashed the design on the IVT controller today dispensing with the thermistors and going 1-wire as I’ve got a load of them lying around the place ...! 

 

Out of interest, how did you mount the 4x20 display ..? I’m thinking a 2G faceplate with a CNC hole is the easiest. 

 

I fitted the display into a 2G blank faceplate with a rectangular hole milled in it and the rear face of the blanking plate milled off flat (there are moulded lumps and bumps that stop the display sitting flush).  To finish it off I used a laser cut stainless bezel: http://www.picaxestore.com/index.php/en_gb/bzl020.html

[PeterW]

Thanks - fits with my idea ..!

 

Next question will be along shortly ... ?

[TerryE]

21 hours ago, JSHarris said:

I won't pretend it's elegant, and it does suffer from the fact that it's not integrated into house LAN, but is entirely stand alone. 

 

Jeremy the easiest way to connect this is through a simple gateway.  If you have a spare serial port off your PIC hub then you can hook it up to a Wifi-enabled processor.  You might find the RPi zero W as the best choice because you can run Linux and script this in Python.  Alternatively you can use an ESP processor and script this in Lua which is pretty Fortran-like.  If you do want to go this second route them you do have access to one of the ESP/Lua gurus, but this is a case of Matthew 7:7 (an exercise for Google)

 

[TerryE]

On 03/09/2018 at 15:44, TerryE said:

As to using SD cards, as you say they fail and regularly.  And that is a total PITA.  The nub of the issue is that the EXT4 file system really assumes that there is a decent wear-leveling flash controller between the processor and the flash memory chips themselves.  Yes the Linux kernel does have some flash support but this is really to talk to the flash controller with garbage collection hints.  This just isn't the case and like all file systems or pretty bare flash devices like your typical microSD card, you will hit the erase limit on hot sectors and the device will fail.  That's why you need an SSD or a board that supports eMMC.

 

I've just been doing a bit of research and it turns out that this isn't the case.  Reputable manufacturers do have an on-card flash controller in front of the flash chip(s) ( and this is often an ARM chip! ) and this controller does implement wear leveling.  See Bunnie:studios - 2Gbyte microSD card and Bunnie:studios - On MicroSD Problems which describes an epidemic issue of knock-off clones where the counterfeiters save cost by leaving out this controller and use a very simple interface which does no wear leveling.    If you sudo cat /sys/block/mmcblk0/device/cid this will output a 32 hex digit output.  Use https://goughlui.com/static/multicid.htm or layout below to decode.  It turns out one of my SD cards is a bit suspicious, and has a questionable life, but luckily I only use them as /boot and effectively never write to them, so this isn't an issue for me.

 

Edited September 4, 2018 by TerryE