Potential usage for buttons/switches/rotary encoders

[luigi311]

Is it possible to use this to send data such as button presses/flipping a switch/rotary encoder? I see its mostly used for sensor data every x amount of time but i would like to also use this to have an esp-32 with a rotary encoder in deep sleep until the encoder is rotated or the button is pressed and send that over to the gateway.

[Devilbinder]

Yes this is possible. All you need to do is wrap the send block in a if on change block. It will look something like this.

void loop() {
    your wake state
    data1 = readButton();
    
    if button change
      FDRS.load(data1,BUTTON_T);
      FDRS.send();
      
    your wait state
}

[timmbogner]

Yep. I think the best method is to have the device circuit configured to wake when any button is pressed (diodes may be needed?), then check which button it was and send the reading.

I have not defined a BUTTON_T type yet, so this is a good place to discuss how to send that reading. My current plan is to have each switch that is connected to a board assigned an id, and the system sends the id of the switch that is pressed. Easy enough? Any feedback?

I would be curious how well you could send raw signal from a rotary encoder over ESP-NOW, but it would probably not be at all practical. You will likely need to handle the rotary signal on your board and send it as button presses or speed or something like that.

[Devilbinder]

Assign the buttons to a bit in the data field of the packet. Since it is a float you can have up to 32 buttons.

    float data = readButton1() << 0;
    float data |= readButton2() << 1;
    float data |= readButton3() << 2;
    float data |= readButton4() << 3;
    float data |= readButton5() << 4;
    //for how ever many buttons you have
    float data |= readButton32() << 31;
    
    FDRS.load(data,BUTTON_T);
    FDRS.send();

The data will look mangled in a json packet but Javascript (Node Red) can translate it.

On the rotary encoder. Assign a value of lets say 360 as the max in the data field. Then get the number of steps that the particular encoder has for a full 360 degree turn.

Steps_per_360 = 50
current_steps = 15

data = (current_steps / Steps_per_360) * 360

It will be the sensors job to keep track of what step it is on and truncate it, if it goes over the max steps.

[lekrom]

Sounds good. I agree that some processing of the rotary encoders should be done on the sensor node side. It will quickly get very clumsy otherwise.