FS1000A 433MHz Tx prevent correct operation of onboard SSR's

I built a temperature monitoring device for my 2 interconnected HW storage tanks using an Arduino Uno. HW tank top temps are sensed using DS18B20 sensors.
Each HW tank has a normally open 240V zone valve that controls the CW feed to each HW tank; this CW feed passes through a YF-G1 water flow sensor before being routed to the bottom of each HW tank.
These zone valves are controlled by Finder SPST 5V/240V SSR’s.The idea being that the flow sensor detects when any hot water tap is turned ON & the Uno closes the zone valve on the coolest HW tank thereby drawing HW ONLY from the hottest tank.
All this works as expected, however, when I try to send data from the Uno to a receiving Uno using a FS1000A Tx & Rx pair, both SSR’s switch ON then OFF at every pass through the void loop()!
I’ve tried 2 Tx/Rx protocols but the problem remains.
So far the only cure is to disable the RF section in the sketch.

HW_tank_CW_feed_with_433RF_Rx_5_11_2018.ino (4.09 KB)

HW_tank_CW_feed_with_433RF_Tx_5_12_2018.ino (26.6 KB)

2 different sketches attached lookin quite different. Describe.
In the first sketch some variables are declared inside loop() so they will be initated every time loop starts. Is that Your intention?

Try to connect the Rf step by step. Include just the declarations, maybe setting it up. Does that work? If so, add one more Rf step. Does that work? Use serial monitor to display key data for debúgging.
Any help? Your code is too complex for me to pick up.

Hi Railroader

The 1st sketch is the receiver & only handles 2 temp readings & the status of the CW feed zone valves ie ON or OFF. The temp variables & zone valve relay status changes over time hence the need to read their vaues constantly hence why they are in the void loop()

The 2nd sketch is the transmitter but also needs to read the temp sensors, send commands to the zone valve relays & LED's so is the more complex of the 2 sketches.

I've used the serial monitor but it doesn't detect the regular relay switching ON or OFF (there is no command performing this switching ON & OFF)

I'm no coder but could it be something to do with the ISR which I believe the transmitter uses somewhere (VirtualWire library)?

I've not tried your suggestion of connecting the RF step by step but I'll give it a try.

Thanks for your input

I’ sorry, what is “ISR” in Your world?
More then once in life I was set to pic up and finish large programs made by other people. Using the technich of test messages telling “I’m here, value is…” was a fantastic help. Reading “a lot of dry code” and understand it would have taken ages… Try it!

ISR = interrupt service routine

Searching both Your codes I don't find any interrupt routine. Hidden inside the library stuff? Never mind. Don't guess, get the hard working brain and hands started, debugging.

My guess is that you have a pin conflict between the VW library and the SSR pins. This is made more confusing by the use of datacoder.h on top virtual wire.

Can you try and write an MCVE i.e. a minimal,complete, verifiable example.

"I've tried 2 Tx/Rx protocols but the problem remains."

One of the protocols didn't include datacoder.h, only VirtualWire.h but the problem was the same

This is an extract from VirtualWire.h:

/// Set the digital IO pin to be for transmit data.
/// This pin will only be accessed if
/// the transmitter is enabled
/// \param[in] pin The Arduino pin number for transmitting data. Defaults to 12.
extern void vw_set_tx_pin(uint8_t pin);

/// Set the digital IO pin to be for receive data.
/// This pin will only be accessed if
/// the receiver is enabled
/// \param[in] pin The Arduino pin number for receiving data. Defaults to 11.
extern void vw_set_rx_pin(uint8_t pin);

// Set the digital IO pin to enable the transmitter (press to talk, PTT)'

This is an extract from VirtualWire.cpp:

/// This pin will only be accessed if
/// the transmitter is enabled
/// \param[in] pin The Arduino pin number to enable the transmitter. Defaults to 10.
extern void vw_set_ptt_pin(uint8_t pin);

/// By default the PTT pin goes high when the transmitter is enabled.
/// This flag forces it low when the transmitter is enabled.
/// \param[in] inverted True to invert PTT
extern void vw_set_ptt_inverted(uint8_t inverted);

Does this mean these 3 digital pins must be used for RF?

Does this mean these 3 digital pins must be used for RF?

No, but they must be explicitly addressed in the constructor, and it wasn't clear with datacoder.h where things needed to be changed. You are safer to leave 10,11,12 to the VW library.

I was initially concerned about the PTT pin on 10. However, that doesn't explain the other SSR.

Still, the minimal example code will be a great help if figuring this out.

I'll try using pins 10, 11 & 12 for the FS1000A Tx & update the outcome here

Thanks for the input

Problem solved by using settings in VirtualWire.h:

D10 = NC (reserved for PTT)
D11 = NC
D12 = Data (Tx) for FS1000A

Thanks Railroader & Cattledog for your help

Well done!

both SSR’s switch ON then OFF at every pass through the void loop()!

Problem solved by using settings in VirtualWire.h:

D10 = NC (reserved for PTT)
D11 = NC
D12 = Data (Tx) for FS1000A

It’s good to hear the SSR’s are now working properly.

In the original code I see this

 const unsigned int pinValveLHTank = 10;      //Finder 5V/240V SSR connected to digital pin 10 (vitualwire 
     set Tx pin to D6)
                                             //which controls zone valve for HW tank in LH airing cupboard

 const unsigned int pinValveRHTank = 5;      //Finder 5V/240V SSR connected to digital pin 5
                                             //which controls zone valve for HW tank in RH airing cupboard

What explains the SSR behavior on pin 5?

I can only assume I made a mistake in stating both relays were clicking ON & OFF. Because the relays operated very quickly & could only be identified by listening for the relay sound (an oscilloscope could have detected which relay was operating) & since relays are close to one another it sounded like both were operating together which obviously wasn't the case.