Why do you think this change is correct?

The CANopen standard clearly defines that a node enters the PRE-OPERATIONAL state automatically, right after sending its boot-up message (section 7.3.2.2.1). So I think the previous behavior is correct.

Ping @Jef-GB, I'm about to close this as I don't see any wrong behavior to fix here. Unless you have a good explanation why it's necessary.

The CANopen standard clearly defines that a node enters the PRE-OPERATIONAL state automatically, right after sending its boot-up message (section 7.3.2.2.1). So I think the previous behavior is correct.

What about non-compliant and buggy nodes? Would it not make sense to just await the PRE-OPERATIONAL heartbeat instead?

It's perfectly normal for a device to not send any more NMT messages after its boot-up. Heartbeat needs to be enabled explicitly. Assuming standard-compliant behavior by default is the Right Thing to do, any known buggy devices could be handled by subscribing via add_heartbeat_callback() and tracking state manually.

It's perfectly normal for a device to not send any more NMT messages after its boot-up.

In that case, there's no need for this change. The docs could be made a little bit more explicit about this, though.

First, can we please move the discussion to the #401 issue and we should close this PR.

Reason: Default behavior change might break existing applications.

But I also see the need to have a "synchronized" state hassle-free. Maybe we can introduce some option for the node, which enables state transitions based on the heartbeat only. Because I think it is a very commong use-case to wait for a device until it finished its internal startup. Currently in my older mc-test projects I use a fixed waiting time, which is bad. In the newer tests, I subscribe to the heartbeat to do another is-ready check, but this would be so much easier if I just could enable this behaviour on the node itself.