or will this create an infinite loop?
The issue is that sometimes I want to combine 3 or 4 switches, and needing a sensor for them all and a listener would make everything really complex.
I can’t really figure this out from the docs.
also I don’t get why there are on_press and on_release events for a binary_sensor
You can’t have two sensors in the same device with the same ID.
What you want to achieve will work, if done correctly. There is no infinite loop because the UDP component propogates state, not events.
Doing it for more than 2 switches does get complex, but that’s just the nature of the beast - it’s a complex problem. You would probably want to use one switch as a master and have each other switch only aware of itself and the master. Then the complexity only increases linearly with the number of switches, rather than factorially.
What part don’t you get? Is it that you don’t like the names, or you don’t understand what they do?
that one i Missed, maybe I could use a broadcast_id for that one.
I will start with 2 switches, And check if I can get away using the same broadcast_id on both devices. then the sensors can have different ids.
but unfortunately today I don’t have the time to test.
there is no press and release on a binary session. technically only to_on and to_off
or something. probably the names of the actions are confusing for me.
then that would be called a switch.
but a different naming would be better.
of if press equals true and release equals false
than at least is is clear only a little confusing.
I here have a different provider per device,
Meaning, with 3 devices I need 2 udp binary_sensors, and then just multicast the same id.
next to that there is a setting update_interval which syncs the states every X settings, But on a state change I would prefer to send the message multiple times. so if the 1ste is missed I don’t have to wait the interval time,
The update interval is a time, not a number of state changes. When a state changes it will be broadcast immediately, then at the update interval all sensors will be transmitted. Because UDP is unreliable there is no guarantee that any broadcast will be received.
If you want to minimise the delay if one is missed, use a short update interval. But there is no way of guaranteeing reception within any given period, and using too short an update interval can be counterproductive as it increases traffic, and therefore the likelihood of a missed transmission. If you need guarantees of reception, UDP is not the right choice.
I know,
But I need it to be fast and reliable.
an automation is HA usually is just to slow.
The previous custom component I used sends the udp package multiple times on a status change, but not on a time interval, this way the udp sync actually never failed.
but there was no esp-idf support, so That’s why I think this new component can work out better.
I’m afraid if I set the interval to 1s, that I’m flooding the network.
1s should not be a problem unless you have many nodes. You can also reduce load on receivers (rather than the network itself) by sending to specific IP addresses, that way other nodes won’t have to process the packet.
in the end, my full configuration will have about 20 devices which will sync using UDP. So I don’t know if that is considered many.
Specifying IP addresses would be a good idea, however my IP addresses are dynamic,
working with mDNS names would work better for me,
of maybe this is already possible but it’s not in the docs.
I think maybe this would work for me. where the value 5 would be configurable.
but I don’t know c++ well enough to know if this is valid.
void UDPComponent::send_data_(bool all) {
if (!this->should_send_)
return;
for (int i = 0; i < 5; i++) {
if (!network::is_connected()) {
sleep(10);
continue;
}
this->init_data_();
#ifdef USE_SENSOR
for (auto &sensor : this->sensors_) {
if (all || sensor.updated) {
sensor.updated = false;
this->add_data_(SENSOR_KEY, sensor.id, sensor.sensor->get_state());
}
}
#endif
#ifdef USE_BINARY_SENSOR
for (auto &sensor : this->binary_sensors_) {
if (all || sensor.updated) {
sensor.updated = false;
this->add_binary_data_(BINARY_SENSOR_KEY, sensor.id, sensor.sensor->state);
}
}
#endif
this->flush_();
}
this->updated_ = false;
this->resend_data_ = false;
}
This way sending always tries 5 times, and even if the network is failing for a bit the device retries.
The only issue Is that I’m not sure about the sleep time, this might be to long for a device.
I tried my sollution above,
without the sleep command because that one is not valid,
So think I can revert the is_connected check all together.
and there are 2 things to mention.
syncing now works perfect on my testdevices, no issues at all during all my tests.
before I had some issues sometimes.
2 I now get this error is a loop.
[20:34:09][W][udp:602]: udp.write() error
So I think I’m getting somewhere, but it’s not good enough.
also I think the retry count should be a setting which defaults 1 for current behaviar. @ferbulous I don’t know, using the Cossid component I only configured all my bulbs as switches.
Edit: the performance update probably was there because I set update_interval to 0s,
not because of my changes.
setting if to never makes the sync never apply also not on status change.