Archived Forum

For what it's worth, if you split Martin's (or Robin's) diverter at the input to the opto-trigger, leaving the current-limiting resistor at the sending end, you can drive the trigger over about 70 m of "telephone pair" (a light gauge unscreened twisted pair). I did it with the cable on a drum, I wouldn't expect any problems unless you run it parallel to a mains cable with a really nasty load on the end. (You've got to get enough interference to light up the IR LED, and that requires some!)
70 m isn't the limit, it's what was on the reel.

Then you can have the triac right next to the load.

I would agree extending the triac trigger would be better, I have a working version of this using some standard (really skinny) bt socket extn wire and it works perfectly. I did consider using (and may again) a rfm remote device based on the work Robin has done in this area, but I'm not convinced on the idea of relying on an rf signal for modulating, any error costs or losses me money via the meter. 

I'm even less sold on the idea of wifi for this purpose (unless perhaps a direct non networked connection) but aside from all that, the relay would need something else to control it based on the data from the emontx and would not follow the grid CT so well.

The relay is perfect for a 2nd load that can be easily controlled via some PV vs consumtion logic, including a manual override, seasonal or environmental influences etc (eg node-red) to consume the PV first and the triac'd load can mop up 

Paul

I was trying to avoid running wire/cable at all, and as I intend to use the Wi-Fi relay to control my heating programming it would be a natural progression to use it for diversion too. Also from a safety point of view, as it's pre-built and runs cool, it may be a better option for less confident/qualified users??

 ...the relay would need something else to control it based on the data from the emontx and would not follow the grid CT so well.
The Wi-Fi relay (ESP8266) has been pre-programmed to accept a MQTT message or http call to change and hold the state of each relay (Martin Harizanov's blog is currently down which gives details), so in theory once the diverter decides to dump excess power, it should take milliseconds for the relay to actuate.

The problem is that emoncms is only updated every 6 or 7 seconds, and that time delay could take me out of the 'sweet spot', rolling into a watt hour so I need to somehow use the output from the emontx.
I could of course use the output from the emontx (removing the opto trigger) and use it to activate a ESP8266 module (£1.82 from Ebay) which would then talk to both node-red and the wi-fi relay via MQTT....

Paul

The relay's mechanical endurance shouldn't present a problem as its rated >30x106 operations.

This is the mechanical endurance. If you switch a significant load with it, the electrical endurance will be more in the range of a few 10^4 or 10^5 cycles.

I don't think its a good idea to use a relay for a purpose like this.

BR, Jörg.

I do remote load control via MQTT over hard wired ethernet (not WIFI). I am switching a SSR which is controlled via a little Arduino + ethernet shield running a simple sketch which monitors an MQTT topic and switches a digital pin accordingly. My emon is running a modified version of Robin's sketch and publishes on/off messages as it decides whether or not we have any excess.

Using *anti-flicker* mode the load is being switched a couple of times a second and my MQTT broker/Arduino+SSR seems to have no trouble handling this. 

Not sure I would like to try it over WIFI however, although it may well work just fine.

@Ben - I presume that you are using the 'Arduino Client for MQTT' for the Arduino/Ethernet Shield, are you using the same client for the emonTX to publish the on/off messages or something different.

@Robert, @Paul, @Jörg - Thanks for the posts, the consensus is this may be problematic for energy diversion especially where switching may occur every few seconds causing relay fatigue and more suited to a 2nd load, but it would be interesting to test the viability of using MQTT to control a Triac as per Ben's post - except over Wi-Fi, ending the reliance on wired systems, but also creating opportunities to create 'safe' pre-built modules to control loads.

Paul

@Paul - you can find the Arduino sketches I am using on my GitHub page;

https://github.com/sumnerboy12/hardwicke/blob/master/emontx_pvrouter/emo...

https://github.com/sumnerboy12/hardwicke/blob/master/mqtt_heating3/mqtt_...

The heating node has the SSR connected to it, but it also does a load of other things, such as monitor 3 temp probes in my HWC and control some other home automation devices. The only bit you are really interested in is the mqtt_callback function, which simply switches a digital output pin when a message arrives on the /openhab/heating/in/<pin> topic. 

So the emon publishes to mqttTopicPvrTrigger (/openhab/heating/in/2) which is picked up on the receiving Arduino and switches digital output pin 2 high/low. This pin is wired directly to my SSR.

Feel free to ask any questions if any of that is not very clear!

I don't know how Google's very recent offering might interest you - if indeed it does.

Does frequent switching reduce the life of the immersion heater?

Is there much heat loss by the SSR?

Yes and Yes.

The rapid cycling of heating and cooling of the element causes fatigue which will affect the life expectancy of the element, however, mine is over 2 years old and is still working ok.

The SSR will create quite a bit of heat, and therefore heat dissipation needs to be carefully accounted for when designing a system - heatsinks etc.

Paul