int relayState = 0;
double temperature = 0;
double temperatureThreshold = 22.0;
void setup() {
Spark.variable("temperature", &temperature, DOUBLE);
Spark.variable("relayState", &relayState, INT);
}
void loop() {
delay(2000);
temperature = sensor.getTemperature();
relayState = temperature < temperatureThreshold;
}
I am getting wrong values for that relayState boolean. I’m logging the data both to the serial port and to a Google spradsheet, and it looks like this:
I thought about that kind of issue as well, but in the code shown there are no int/double conversions. temperature, temperatureThreshold, and the return value of sensor.getTemperature() are all double. There is no conversion to or from int.
The result type of < should be int so no conversion there either.
That’s a good point… I forgot we were doing a logical check before doing the logical to int conversion. Silly me.
Have you tried what I suggested? Just curious what happens.
I’d have to read up some more on how automatic conversion is done. Perhaps some kind of conversion is still happening. It would be interesting to also try declaring relayState as a double and see what happens
@harrisonhjones’ variant does seem to work correctly. I haven’t seen a wrong relayState value yet. I’d be curious to hear from the Spark team if this is correct behavior.
I would be very tempted to try it without the Arduino/Spark preprocessor, assuming you can write some function prototypes to make it compile as a straight C/C++ program.
But seriously have you tried @bko’s suggestion? The spark preprocessor can be ruthless sometimes. My go-to ‘i’ve tried everything what do I do now’ troubleshooting step is to disable the preprocessor.
I will try that next. Is #pragma SPARK_NO_PREPROCESSOR documented somewhere? I wasn’t aware of that. My code seemed to compile fine when I added it, so I’ll let it run for a while like this now.
Here’s my thought, get rid of the uncertainty of your actual temperature reading and just make sure the code works right first. I created an array of doubles with the values you reported in your first results post. Then a matching array of expected results of the expression value < control. Then I tried all of the different methods suggested here after the standard if else logic. Then I looped it over and over to make sure the actual double comparison did not change from iteration to iteration due to some weird non-atomic operation in the code. Results are that every way I try testing it works fine, consistently. I even tried adding weird random extra precision to the values in the array which your temperature reading probably have? Maybe not, I seem to recall Serial.print() truncations float/double precision… but thought the default was 2 decimal places.
But that the line you want to replace were not working would require an error in the complier. I’ve yet to spot compiler errors - its gcc so unlikely to be at fault, or, at least, to have such a basic fault.
I think the library you’re using may be at fault. It’s using “<<” left-shift bit operator and I think the humidity value may be trampling on the temperature value. I think the original library is assuming 16bit int rather than 32bit?
Note that the C-compiler spec says always sizeof(short)==16, and always sizeof(long)==32 but sizeof(int) cab be 16 or 32. This is always true. On a 16-bit processor an int (or unsigned int) is usually 16 bits, and usually 32 bits on a 32bit processor. I think the vars defined as int in your library some of them need to be redefined as short so as (1) to remain portable and (2) to work on Spark as well as on Arduino.
While it might be on the docs somewhere it’s essentially “documented” on the forums… not ideal but I don’t know if they can put a “If you’ve tried everything and it’s still not working try this” section.
#pragma SPARK_NO_PREPROCESSOR is a band-aid for a bigger problem: the preprocessor and hopefully it will be fixed at some point.
As a general principle I thought it was accepted by the powers that be that all the info we need to be able to use the Spark Core to its fullest intended extent should be available in the proper docs. All acknowledge this isn’t the case, but some seem to regret this not at all. At the risk of once again being told I am being snarky, there is information in the heads of some insiders which could be easily documented, should be documented, and is not being documented. Having to resort to the forum is not ideal, as you yourself say.
As to this specific issue there is just no way that anyone could realistically be expected to know of the existence of #pragma SPARK_NO_PREPROCESSOR directive. That it exists is not as useful to me (or anyone else) as you might think: What are the circumstances and consequences of its use? Or is it another of the several things we need to try in various combinations (2^several) to get code working? Or must I read the source code?
Having to become intimately familiar with the source code of the firmware of the Spark Core ought not to be a prerequisite to using the thing, and those who hold a contradictory POV do, in my (snarky) view, sabotage the project.
The ambition of the Spark.io organisation seems (rightfully) to me to conquer the Internet of Things world. The handful of well-intentioned source code experts doling out helpful advice, but seemingly not documenting what they know, is not scalable: The forum is not easily indexable or searchable, there is bad and good and contradictory advice, and no way to tell the difference.
Is this another “shoot the messenger” posting from he with the objectionable tone?