digitalRead() returns HIGH or LOW. Right now, those may be integers, maybe not and not necessarily forever. You can deal with this immediately by turning it into a boolean, viz:
bool isPressed = digitalRead(somePin) == LOW;
If you want convenient constants and code easier to read and fix, you can
# define PRESSED LOW
or in the 21st century
const auto PRESSED = LOW;
The same care is necessary when using digitalWrite().
a7
There are currently a few board packages where digitalRead() returns the enum PinStatus. LOW and HIGH are still equivalent to 0 and 1 respectively, but the type difference can cause problems in certain situations.
Right.
Using the technique I posted means…
I don't have to know, remember or care about those details. And whether they might change right under my feet.
a7
isEnterButtonPressed is initially false but once set true is never reset.
I didn't look all over for other buttons that stick like that.
This would be the benefit of writing or using some kind of button handler, so details wouldn't need to be strewn about the code.
a7
Evening moderator.
Would it be possible to follow @alto777 suggestion and re-open my previous topic and add these comments to the end of it, or is that going to make the combined topic way too long?
Please post a link to the topic that you want re-opened
Evening @UKHeliBob This is my previous thread Nearly SOLVED Using While function is only giving a partial answer - #118 by johnem51
In view of the number of posts in the previous topic (172) I am not sure that it would be wise to merge them. If anyone wants to refer to it they can use the link in your post
Thank you @ UKHeliBob, I quite agree.
Ho @camsysca All of the \ are in the original code before copying/pasting it to the Forum. I used the “copy for Forum (markdown)” in the Edit drop-down box before pasting the code to the Forum.
It would, however, be helpful to place a reference in your opening post in this thread, pointing back to the previous thread. In future, please do that, as the content is then available for the new thread.
Thank you for considering this matter…
Hi John
Then may i ask, what platform you’re using? Additionally, there are two post modes available, did you try changing it to see if it makes a difference? The reason I’m so focused on this is because if you get that code post just right, it’s a single button click to capture it, and a pair of clicks to paste it into either the IDE, or Wokwi, for further inspection/testing. Otherwise, it’s a laborious edit, and results in code that may or may not perfectly reflect what you posted.
Thanks @camsysca Link now added to my earlier post. I am using Windows 10 and IDE 2.3.6.
Ok. So, I can’t reproduce the ‘feature’ on Win11/IDE1.8.19; maybe someone else can point out where those backslash characters come from. AFAIK, it’s a recent aberration, as I’ve only been seeing them for, at most, a couple of months.
Thanks for the update to the original post, it does help for context.
Is this topic solved, or do you require further guidance from the community? I can’t see a resolution in the recent posts.
Thanks @PaulRB that is a lot of work you have put into this project, and some rethinking that I need to try and get my head around. I admit that much of the code I am using has been cribbed from others, and I have not necessarily understood exactly what the full meaning was, but I managed to get it to more or less work for me and have been “patching things up”. I think the first stage will be to rethink the button push code, as that is basic to what I want to be able to achieve. Then I can move on to newer complex things like “struct”.
It's really simple. When you see, you will wish you had known before, and saved yourself time and effort.
struct Settings {
float temperature_setpoint_range; // C
float temperature_setpoint_club; // C
float temperature_setpoint_airgun; // C
... // All the other stuff you want to save to EEPROM
} settings;
Then you can save to EEPROM like this:
EEPROM.put(0, settings);
And use the values in your code like this:
if ((range_sensor.getTempCByIndex(0) <= (settings.temperature_setpoint_range - deadzone))) {
digitalWrite(range_relay, HIGH);
wouldn't a struct/table like this simplify things
in other words avoid unique funcitons for each room
Sun 2025/11/16 14:38
21.0^ 20.3 range
20.0^ 19.5 club
21.0^ 25.0 airgun
struct Tbl {
unsigned char PinRelay;
unsigned int EeAdrSetpt;
unsigned int EeAdrTimeOn;
unsigned int EeAdrTimeOff;
DallasTemperature sensor;
const char *desc;
float setPt;
float setPtNormal;
float setPtOverride;
int timeOn;
int timeOff;
float tempC;
bool active;
bool heatOn;
} _tbl [] = {
// Pin ---- EE adr -------
// Rly SetPt TimeOn TimeOff
{ 11, 0, 12, 16, SensorRange, "range" },
{ 12, 4, 20, 24, SensorClub, "club" },
{ A1, 8, 28, 32, SensorAirgun, "airgun" },
};
const int Ntbl = sizeof(_tbl)/sizeof(Tbl);
i don't see where buttons are used except to switch between Normal and Override modes
i don't see how termperature set-pts are adjusted using button or to select a room for a specific set-pt
it seems the user-interface code is missing. the user interface is often a project in itself, often a state machine and requiring
and then there's the code dealing with wall time
As I have written in the previous thread.
User @johnem51 stuffs in more and more over-complicated code by trying to avoid to learn effective coding and avoiding to modify “working code”
And now you come back asking other users to re-analyse your messy code.
By just “point me to my error and correct it”
I guess as many lines as your code has now it will take less time to rewrite it all compared to analysing the existing messy code
The ones in the macro definition are suppose to be there, if that is what you are referring too..
They allow for the macro to continue to the next line..
Like you, looked strange to me too, so I looked it up..
sorry.. ~q