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 would really like to get OTA working here as it's freezing outside and I have to go there to update the software in the greenhouse control system.

So please, can we have a 'how to' step-by-step guide to OTA? Please?

S.

Merry Christmas and a Happy New Year to all of you on (or behind) this forum.

Here's to 2018 and a much better year for us all!

Seasons greeting to all of you. Hope you have a nice festive season.

@bc123 said in I am in need of some programming help.:

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.

Good.

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

Good.

and is transmitting to my Arduino receiver, which is tied to a pi running Domoticz.

Good.

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.

@Stevanov

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.

Just to say I wish you all good health in 2021 and thanks for the stimulating discussions and friendly forum.

god Jul och Gott Nytt År!

@nekitoss If I were you I;d reflash the bootloader and chec again. I got my pro mini with ebyte nrf24 to work and register with the gateway all the way down to 1.63V, so somethingi is wrong if you are loosing it at 2.7V (which is also as it happens, a BoD setting for atmel 328p). For the test I used minicore bootloader iwth Bod disabled and 2MHz clock. Bench power supply for the voltage variation.

@virtualmkr An insteresing read about a problem that affects some people.

I had a similar first reaction to @mfalkvid, that setting a random time to wiat for each resend might help.

The solution I have used is to have multiple gateways to reduce traffic and chance of collisions. It only needs a pro mini and a NRF, so not a huge outlay for a simple solution. But I agree that if it can be improved internally than it would be a good thing.

The NRF's can listen on 6 'pipes' simultaneously, so maybe a second pipe' could be used as a network engaged signal?

I guess we also need to consider that mysensors is not just nrf but aims to be radio agnositc as well as any impact on power usage for battery nodes.

@tssk

The 2.7V is set in the fuses, you can go a lot lower if you disable Bod completely. I tested one with nrf24 and it worked down to 1.64V.

I think you will find that all the 'good stuff' from the low power library is included in mysensors sleep function anyway.

I suggest using minicore (it is easy to install and all works from within the arduino IDE you are used to) and set internal oscillator and disable BoD. You will need a programmer (a few dollars) or you can use another arduino as programmer. but that is more time consuming to set up and easier to mess up as well!

Good that you got rid of the booster!

@mfalkvidd Yes - you got me

I was confusing it with the battery pir which is 15-16uA in trigger mode. But yes, 15mA in Tx mode with a nrf24 module.

Maybe it is time for me to hibernate for a few months after all .....

@tssk That is 12.5mA (12500uA) in sleep and up to 90mA (90000uA) in transmit mode. Compare that to my door/window sensor which is <5uA sleep and about 15uA transmit with nrf24l01+). Your current draw is too high for most 'normal' batteries to last very long as you have found out.

Minicore info and install instructions is here -- https://github.com/MCUdude/MiniCore.

Pull-up resistors are on the pcb and connect between data and Vcc as well as clock to Vcc. You won't gain a lot tampering with those with the figures you have posted so I would forget about those at the moment and concentrate on more productive things to get a lower current.

here is the bit of code to only send sensor variable when it has changed.....

if (int != oldint) {
    send(msgInt.set(int));
    oldint = int;
  }

This is used in my door sensor and can be used with any sensor variable name.

ALso of help would be to re-flash the node with MY_DEBUG to see how often your node is measuring and sending data. It shows if your prog is working as your expected it to (or not).

Anoother thought is that the sleep interval does not have to be fixed. You can vary it so that some times of day it is 20-30mins between read/send and at others you can reduce it if you think you need to.

@virtualmkr That is useflul to know - thanks! - As it happens I think I had my first wdt 'kick' early this morning as the Gateway with the wdt on was showing as up for 3 hours instead of the 4 days I was expecting, so it restarted and all is still working

@tssk Sending 240 messages a day is quite a lot for a battery node. I think you will need higher capacity batteries with that frequency of sending (is it really essential to send that often I wonder?).

Anyway, I am also testing battery nodes and as far as I can see the lora and bme are likely taking a lot of power. They must be 'put to sleep' as much as possible. AFAIK lora is an abbreviation of 'long range' and therefore means 'more power'. Can you test the current drawn by just the radio in sleep and transmitting?

Also, bootloader - I highly recommend using the minicore bootloader with internal 8MHz, bod as you wish (I ususally disable) and try again. My sleeping nodes use less than 5uA in sleep and I am trying to get that even lower this week.

Also check the value of pull-upresistors on the boards, they can be on the low side and perhaps better with higher value external ones (something I hope to test tomorrow as it happens).

Also temperature and humidity will have an effect. I put one test node on a colder NE facing window which has slept all the time except a twice daily battery check and send value only if changed. It is the only node to have changed from 100% to 99% in a week, so the colder window is clearly having an effect on the battery life in this situation.

As @mfalkvidd implied I would get rid of the stepup booster if at all possible, they are not so efficient and can produce a lot of noise on the power line. Can you go to 3xAA batteries? What about an 18650 li-on or two in parallel?

Finally check solder joints. A dry joint or cold joint may look OK but measure them with a meter just to make sure.

@zboblamont & @mfalkvidd - Thank you for that. It never occured to me that rounding might need some help. But now it makes logical sense.

@mfalkvidd I guess if you used 'bankers rounding' you would always end up with 0.

@Melih-Kulig Thanks - #i actually used the code above and it has been working OK for the last 10 days, so no bad effect. I don't know if the watchdog has had to kick in yet but it seems not.

@mfalkvidd Good News!

But I am curious where the "+ 0.5" vomes from in this line.....

int batteryPcnt = batteryMillivolts / FULL_BATTERY / 1000.0 * 100 + 0.5;

???