Sensebender Micro

[tbowmo]

@akbooer

Should be doable with an arduino as isp. Another option is to use the serial upload.

[jovo]

I am a noob in coding so I need some advice for tuning the sensebender.ino
current observed problems:

1. sensor values transmitted every minutes
2. battery level info seems wrong

I am running the default senseblender.ino.

on 1) What I understood in this forum, it should transmit the temp. values only every 30min (or direct when change is >.05). However, I see them arriving in my controller (Domoticz) every minute. What should I change to have it send every 30min?

on 2) I observe in Domoticz that the battery levels reported (in the Devices section) are inaccurate. For example: one sensebender with 3.2v measured power reports 80, where I would expect round 100 (this one has new batteries). Other sensebenders with still 2.63v report 53. How to calibrate the battery measurement?

I have been searching this forum, but was unable to find the answer.
Alternatively, a pointer to a wiki on sensebender.ino that has this explained would work as well.

[tbowmo]

@jovo

The firmware that the sensebender is shipped with is pretty old, compared to the one that's available in the current master branch of mysensors library. A lot have been done to do better transmit control (like, limiting number of transmits etc.)

About the battery voltage, the sensebender is measuring against an internal vref, which isn't that accurate. I can't remember the specifics at the moment, but it's hidden somewhere in the datasheet. The measurement method has a lot of inaccuracy, but on the other hand it saves external components and power.

I didn't focus on it, but one could perhaps make some kind of calibration routine, use a known supply voltage and do some internal calculations and store an offset in eeprom.

[Fabien]

@jovo for battery mesurement it's correct 100% is for 3.3V and 0% for 1.9 V (BOD fuse setting). so for 2.63 you have 52,14 %

[martinhjelmare]

@jovo As @Fabien wrote, the default code puts 3.3 V as 100%. Look for the percentage calculation. You will see that it's basically (vcc - 1900)/14. This makes sense if using a step-up converter where you get 3.3 V. But if connecting directly to two AAs, 100% should be around 3 V. So just replace 14 with 11 in the calculation.

[jovo]

Thanks for the comments and suggestion.
Now I have installed the master branch code from the mys. library.
Unfortunately no change. Still very frequent updates (under the same circumstances).
I sense it has something to do with :
bool tx = force;
but I am not quite sure where to change it in.
I will continue my search.....

[tbowmo]

@jovo

There is a small error in the sketch, that falsely converts floats to ints. Look at line 243, it's dividing by 100:

float diffTemp = abs(lastTemperature - (isMetric ? data.celsiusHundredths : data.fahrenheitHundredths)/100);
float diffHum = abs(lastHumidity - raHum.getAverage());

This should be changed to 100.0 instead. This way the calculation is returning as a float.

float diffTemp = abs(lastTemperature - (isMetric ? data.celsiusHundredths : data.fahrenheitHundredths)/100.0);
float diffHum = abs(lastHumidity - raHum.getAverage());

[5546dug]

@fabian how is the box working out were there any mods and are the stl files ready yet?

[jovo]

ok, it seems the aggregated upload is solved with the change from Thomas.
Now I modify the "14" in "11" as suggested by martin. I have 105% now, but that could be right because I measure 3.1V from my 2 fresh AA's

The only 'new issue' I discovered is that one sensor actually stops being received updates from due low power. The measured voltage on the batteries is still 2.1V and the battery indicator was at 23%.
Could it be that I have bad fake radios that don't operate lower then 2.1V? (since there is no other external components added to my setup, I suspect only the radios).

[Fabien]

@5546dug said:

@fabian how is the box working out were there any mods and are the stl files ready yet?

Sorry, my 3D printer is out of service, I'm waiting for chinese parts ... I will post correct STL files in 1 or 2 weeks.

[mvader]

I'm having trouble with the transmission times.

// How many milli seconds between each measurement 900000 is 15 minutes
#define MEASURE_INTERVAL 900000

// How many milli seconds should we wait for OTA? 3000 is 3 seconds
#define OTA_WAIT_PERIOD 3000

// FORCE_TRANSMIT_INTERVAL, this number of times of wakeup, the sensor is forced to report all values to the controller
#define FORCE_TRANSMIT_INTERVAL 30 

// When MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes.
// Between the forced transmissions a tranmission will only occur if the measured value differs from the previous measurement

I would expect a wake up and measure every 15 minutes. transmit if greater than .5 and go back to sleep
also i would expect a forced transmission every 30 minutes.
but that doesn't seem to be happening.
here are my last few transmit times
4:07pm
5:59pm
6:15pm
6:47pm
7:50pm
8:34pm
9:10pm

I don't see a static 30 minute transmit.
(from 4pm to 6pm?) i'm sure the temp and/or hum changed in 2 hours

any suggestions on what may be wrong?
default sketch (1.3 from git) but changed the measure intervals
sensor lib 1.5
thanks

[Dwalt]

@mvader If your interval between readings is 15 minutes and the force transmit interval is 30, your actual interval is 15minutes * 30 = 7.5hours. Also, see this thread for sleep time accuracy. 15 minutes of sleep can last 16-17 minutes...

[mvader]

@Dwalt said:

@mvader If your interval between readings is 15 minutes and the force transmit interval is 30, your actual interval is 15minutes * 30 = 7.5hours. Also, see this thread for sleep time accuracy. 15 minutes of sleep can last 16-17 minutes...

really.. hmm
so if you look at the default comment
when MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes.
That says measure for temp/hum every 1 minute - send if greater than .5 (defined later in the sketch)
regardless of what goes on send stats every 30 minutes

can you help me understand why those 2 number would be multiplied together? one shouldn't have anything to do with the other.
i read that as they are definitions for 2 different process.
but i may be totally misunderstanding.

I do buy the sleep accuracy part of it though :)

[Dwalt]

@mvader No, it is not 30 minutes, the FORCE_TRANSMIT_INTERVAL counts the number of 'wakeup and take a reading' events, which in the original sketch is every 60 seconds. After 30 wakeup-and-read without a transmit, force a transmit. If you change your FORCE_TRANSMIT_INTERVAL to 2, it will transmit every 30 minutes if the readings do not change more than 0.5.

The MEASURE_INTERVAL is based upon time (millis) and the FORCE_TRANSMIT_INTERVAL is based upon counting events (wakeup cycles).

[mvader]

@Dwalt said:

@mvader No, it is not 30 minutes, the FORCE_TRANSMIT_INTERVAL counts the number of 'wakeup and take a reading' events, which in the original sketch is every 60 seconds. After 30 wakeup-and-read without a transmit, force a transmit. If you change your FORCE_TRANSMIT_INTERVAL to 2, it will transmit every 30 minutes if the readings do not change more than 0.5.

thanks for the clarification! :+1:

[mbj]

@hek said:

@gbfromhb

D3 is available on the side-pins. D2 is routed to the radio but can be used with some hacking.

I need 2 interrupts and would prefer using the external interrupts even though it might work with pin change interrupts. When looking through the forum I saw this answer from @hek but have not found any further reference to how this should be done in order not to disturb any radio functions. Anyone knows?

[tbowmo]

I don't know if the radio actually drives the interrupt "output" pin on it's pinheader as default, or if you have to set it up when initializing the radio (@hek might have some input on this part :))

If it drives the interrupt pin by default, then you need to either cut a trace on the sensebender, or cut / remove the pin in the pinheader on the radio module.

[hek]

@tbowmo said:

I don't know if the radio actually drives the interrupt "output" pin on it's pinheader as default,

I think it does actually.

[mbj]

@hek Is it needed for the radio to work or can I just cut it (seems odd to attach the radio to D2 if it is not really needed for anything).

[hek]

No, it isn't currently used by the MySensors library. It could be used to wake up the board when detecting radio transmissions...
But keeping MCU sleeping and the radio listening still uses up batteries far too quickly so I guess it's still not an option.