I thought I'd share a part of my 'workshhop'. Only part of it due the rest being in a bit of a mess at the moment, so here is the 'good' bit......
I have a cool project
So does everyone else
I hired someone to do about a year ago, but it never worked entirely.
Why is that?
need some help with the programming.
Then post your code and the issues you are facing and someone might help you out.
Project: Driveway alert system, looooong driveway.
So it's just a basic 'alert system' - good.
I have 4 sensor beams shooting across the driveway and they are spaced about 100' apart from each other.
That is good if that is what you want/need for your cool project.
Each can provide a NO or NC contact.
I have conduit running between all 4 points
Good idea if you don't want jammable RF.....
and was planning to run Ethernet wire between them
So only empty conduit at the moment then?
The board has a LORA radio on it
and is transmitting to my Arduino receiver, which is tied to a pi running Domoticz.
I hired someone a year ago to build a system for me using 4 transmitters (one for each sensor),
You already told us this bit.
but I don't think he knew what he was doing.
Why is that?
We got several running temperature/humidity data
That wasn't the original 'alert' spec was it? Or maybe it was? Maybe it is supposed to be a driveway alert system with temperature and humidity sensors 100 feet apart? Who knows? What are you 'really' wanting to do here?
but, the input pins don’t work like they’re supposed to.
So is this faulty hardware issue then?
Why 4 sensors on the driveway? Eventually I’ll install my railroad signals and be able to direct one way traffic up and down the driveway! How cool is that!
If you really have that much traffic on your driveway then it might be a better idea to have a 2-lane driveway.
Help anyone? Happy to compensate for your efforts!
How can we help? You posted an 'alert' dream that later included temperature and humidity. Then it morphed into a traffic control system (either automatic or manually controlled, we don't know which at this stage).
Then you ask for programming help and don't even post a single line of code.
Yes that was all a bit 'tounge-in-cheek' but hopefully you get the idea.
First define what you actually want.
Post code you are trying to get working.
Post drawings of how it is all connected up.
Post photos of the project.
Where is the project located on this once fine planet?
Where do I get my compensation from?
The current NRF24 set up is more secure than bluetooth or wifi from attack.
I say this based on the fact that anyone with a laptop, mobile etc can have software to crack/hack/spoof/inject into bluetooth or wifi. It is not that difficult for kids to do.
The NRF is another matter as to achieve this on that radio module would require acquiring a module, setting it up with a pc/phone and then getting software to attack it.
People often go the easiest route and I am less worried about nrf24 than I would be if the system used bluetooth/wifi or cloud.
Just my thoughts on a dark and wet Monday morning.....
@TheStaticTurtle You are using an older version of mysensors. 2.3.2 is current so first of all upgrade to that.
Second, looking at the node log it never finds the gateway. FPAR is "find parent" and it never does, so nowhere to send the data. The "!TSM:FPAR:FAIL" is also a clue as to no comms with the gateway.
Why this is I don't know as you haven't posted your code.
Your best bet is still to simply change to a different unused channel.
Nrf24l01+ has over 100 channels available, why insist on using one in use by someone else nearby?
Even if you do encrypt all data the radios will still suffer due the the high level of signals around swamping the receiver front ends and reducing sensitivity adn increasing liklihood of packet collisions.
Far better to find a clear channel and use that, but it's up to you at the end of the day.
There are 2 ways of doing this.
First is to have a 'dumb' node that sends data to the controller. Then the controller decides if the relay has to be on or off and sends a signal to make it happen. This is how many systems work.
The down side to this is that if the gateway becomes unavailable or the controller crashes, the relay state will not change.
Personally I prefer to make the node as smart as possible, collecting data, doing calaculations and performing actions while sending the results to the controller for display. The controller can still send commands to the node but if the gateway or controller fail the realy will still operate as expected.
You could even have the nodes request/send data to each other to confirm the status of the realy or anything else for that matter. That's really a third option
So I would approch it by haing node 1 get temp, send to controller and node 2. Have node 2 decide on realys status, switch relay and inform node 1 and controller of the status change. I am sure you can think of variations on this as well because you know best how you want things to work.
@Yveaux I'm sure it's in the forum posts somewhere but I don't have time to look for it.
Maybe you could do a list of what is and isn't possible in void receive to mitigate further confusions?
It's a nice find and thanks for sharing it and if someone adds support via GPIO link to a hackRF1 then it will go to 6GHz!
Personallly I think it is a little over hyped. The IR learner/replay is fine and I would expect a lot of 'built-in' ir codes from the start.
As for the RF side, well no mention about how it will deal with rolling encryption (used by most garage doors amongst others), no wifi or bluetooth (so many 'hackers' won't even bother with it) and a high price tag ($169USD) which is high for most 'kids' out there.
Also, any properly implemented RFID system will have measures to counter this device (I played with them a few years back and got it working where a clone card would not work).
I see there could be issues with it's use by some people, but I won't be ordering one. I HackRF1 will do all the RF send and receive up to 6GHz and an arduio can do the IR side. With HackRF1 about the same price it's the better option, but will require more learning to get going and a SBC to power it, still, it would be my choice if I wanted to go down that route.
@yourry Don't use serial print inside the receive function.
instead set a variable in receive and test for that in the main loop and then send serial from the main loop.
This is probably all the problem is........ probably.......
@Skysurfer14 I am not totally sure what you have done, so this might help you get more help.
@nzbaxterman You are welcome - It's a bit difficult to imagine the setup you want, but here a bit more to try and help.
All sensors in the barn will need to communicate with 'something' in the barn. Due to all metal walls you may get reflections that will affect signals so moving antennas 20mm at a time to try and find the 'sweet spot' will probably help.
Outdoors a 200m run will need a 500mW Nrf24l01+ or you could use lora radios. With the nrf it would be cheap and good to use a yagi (directional) antenna just for this link. You will want a yagi mounted at the barn and at the water tank pointing directly at each other. A helping hand an some walkie talkies would make this reasonably easy!
Mount antennas a high up as you can and avoid any obstacles in the path between antennas (including trees).
Let us know how it turns out!
You need to place the antennas outside where they can 'see' each other. A pre-made length of coax and a small fixing will be required. Try to think of ways to keep the coax cable run as short as possible as this will be a big help with the low power levels we generally use.
If you can put the whole radio module outside in a weather proof box then that would be another option.
@monte You will never get rid of all risk, it is a fact of life.
Considering that the diagram above shows a 500mA fast blow fuse, I doubt it will last a whole second with full mains across it. If worried about the fuse then use 2 or 3 in series.
As for the fire risk even the first link says "Under normal utility voltage conditions, this is not a problem."
The fact is that this is the best solution that gobal engineers have used for decades. It is an industry standard for protection. It is even used in Fluke multimeters to protect their input electronics from over voltage.
If you feel that there is a better solution with the same or better protection and lower risk, then please share it.
The thing I am saying is just tha MOV is a device conneted in short between live >and neutral and with ability to fail short and not open it poses potential risks.
No it does not pose 'potential risks' - it removes a very real danger to the equipment and persons using that equipment.
A MOV is OPEN circuit when new. It only goes into conduction when a voltage greater than the value on the package is reached. When this happens it shorts live to neutral blowing the fuse and protecting the rest of the circuit and the person(s) using the device. This way it shorts the voltage surge to neutral (often ground) and in blowing the fuse it disconnects the power from the device.
Without a fuse in place it would be an issue, but that is why you ALWAYS use a fuse with a mov.
@Encrypt The capacior and inductor may be optional for some useage, but they are there to reduce smaller spikes and interference on the power line entering the power supply and I strongly recommend that you use them for your application.
As for the mov, your mains voltage is 230V+/- 10%. This gives us a range of 207V - 253V AC. A 250V mov should start to conduct at 250V, so in this case it could blow even if the AC is within specification.
Usually the mov is there to protect against large spikes or surges from lightning strikes or faulty equipment supplying power to your area. In my opinion the 350V in the statsheet you have is spot on for this application.