Hi Chris,
ah cool, I hadn’t seen this yet, thanks for the pointer. This looks really interesting [1]. If I understand it correctly, this new event-based approach also addresses my earlier question about exposing more detailed PLC state, right? I was wondering whether it’s possible to detect that a PLC is intentionally turned off. From what I can see, there are currently events like DISCONNECTED and CONNECTION_LOST. Do you think it’s feasible to distinguish a powered-off PLC from other connection loss scenarios, or is that not really possible at the driver level? Can this already be tested using the current SNAPSHOTs? How can I access these events over the public API via PlcConnection, or is this only used internally? Philipp [1] https://github.com/apache/plc4x/commit/f87bd6b686a15fc0e27abc573cc252aeaa97d6e0 Von: Christofer Dutz <[email protected]> Datum: Dienstag, 27. Januar 2026 um 10:42 An: [email protected] <[email protected]> Betreff: AW: AW: How to handle disconnects? Hi all, @sebastian I think that case is generally only one connection instance of one driver type that is impacted. With PLC4X most people I’ve seen use some sort of connection-cache + scraper pattern. Adding the re-connect to the driver itself would make it more complex. Also would it not rid the client from having to implement strategies for handling outages. Just as an example: If a PLC goes offline during a read operation … if we implemented the re-connect functionality into the driver, then it would try to re-connect until it reaches the max request timeout. Then the client would need to handle it. I am proposing to generally make the client have to deal with such situations as it’s often simply the normal use (as Philipp just mentioned) … this way we have less locks, waiting threads etc. to manage and hereby simplifying things greatly. @philipp … have you seen the latest change that I implemented in the latest SNAPSHOT version, where I replaced the old connected/disconnected callbacks with one method that receives an event that contains a lot more context? Currently the PLC4X drivers only make use of CONNECTED and DISCONNECTED, but my ToddySoft implementations use quite a number more … such as „device is in stop mode“, … With the SPI3 funded by NLNet I’m going to develop a brand new cache and scraper which should hopefully reduce the number of problems. Chris Von: Philipp Zehnder <[email protected]> Datum: Dienstag, 27. Januar 2026 um 10:20 An: [email protected] <[email protected]> Betreff: AW: AW: How to handle disconnects? Hi all, we’re also seeing connection-related issues in Apache StreamPipes when using PLC4X and I wanted to briefly share my experience. At the moment, we maintain our own cached connection handling (SpCachedPlcConnectionManager) [1]. This was introduced as a temporary workaround, but unfortunately it does not solve all issues we observe. The two main problems we currently face are: Connections silently dying In some cases, connections become unusable without a clear disconnect signal. Our assumption is that a “zombie” connection remains in the cache. When we stop all connections for a PLC, wait until the maxIdle time has passed, and then restart polling, reads start working again. All cached connections breaking at once For some older PLCs, especially when reading larger arrays, we occasionally see that all cached connections break simultaneously. Unfortunately, we cannot reproduce this reliably so far. That said, I do like the general idea of the current connection cache automatically regenerating connections. Even if I probably can’t help much with the implementation, I’m happy to support testing. One additional (slightly related) question: In our setups, PLCs are often intentionally turned off for longer periods (e.g., over weekends), while we continue polling at a fixed interval. To avoid unnecessary load and error noise, we currently implement our own backoff strategy to reduce the polling frequency. Would it make sense to support something like this as part of the interface? Alternatively, would it be feasible to expose a clearer PLC state (e.g., online, offline), so clients can distinguish between real errors and PLCs that are simply powered off? I hope these points help with the discussion, and I’m interested in your feedback. Cheers, Philipp [1] https://github.com/apache/streampipes/tree/dev/streampipes-extensions/streampipes-connectors-plc/src/main/java/org/apache/streampipes/extensions/connectors/plc/cache Von: Sebastian Rühl <[email protected]> Datum: Dienstag, 27. Januar 2026 um 09:47 An: [email protected] <[email protected]> Betreff: Re: AW: How to handle disconnects? An option would be to add a auto-reconnect option. At least that is what I've seen on gopcua. - Sebastian On 2026/01/27 08:23:28 Christofer Dutz wrote: > Hi Cesar, > > I think from your email, that you would agree to not put reconnection logic > into the operations themselves. > If the connection fails for whatever reason: Fail fast, report this to the > client in a clear way and have the client deal with it. > I just mentioned the connection cache, as I’m personally using that for all > of my polling operations and it generally takes care of the reconnect > automatically. > > I think the only driver that has some sort of auto-connect functionality > (even if it’s a bit broken) is the ADS driver. > > When I update that as part of my SPI3 migration, I would like to update it in > a way that if the connection is lost, it doesn’t try to reconnect. > > Chris > > > > Von: Cesar Garcia <[email protected]> > Datum: Montag, 26. Januar 2026 um 21:31 > An: [email protected] <[email protected]> > Betreff: Re: How to handle disconnects? > > Hello, > > In our particular case, control over the driver is important. > In the case of the S7 driver, the "ConnectionStateListener" interface is > implemented on the client, which we use if we actually experience a driver > disconnection. > For the "Modbus" driver, we must verify the connection based on whether an > exception is generated during the read/write process. > Specifically, I would focus on the first case: active notification from the > driver to the client regarding the connection status. > From what I've seen, other drivers don't support the > "ConnectionStateListener" interface, even though it's available. > > Our use case doesn't require a connection cache. > > My two cents. > > El lun, 26 ene 2026 a las 11:59, Christofer Dutz (<[email protected]>) > escribió: > > > Hi all, > > > > As I’m currently fine tuning with my new drivers, I wanted to take this > > discussion here as I think it has value to the project. > > Unfortunately many reported issues are related to connection losses, plc > > updates and connectivity issues. > > > > In my current case I was making my ADS driver more stable. Like ours this > > generally supports online and offline version changes. > > During an online change the PLC remains online and we can instantly start > > re-loading the datatype and symbol tables. > > With an offline change, the PLC usually reboots and is firstly just flat > > offline, then it comes online again, but is not yet able to handle > > connections. > > > > While with the online changes it’s not an issue to transparently reload > > the tables and continue running, with offline changes this becomes more > > complex. > > Initial Claude wanted to update the read logic, to do automatic reconnects > > with exponential backoff. > > > > I however intervened. > > > > As all of my use-cases generally use the connection cache and follow a > > pattern of „get a connection -> do stuff -> put the connection back“, I > > think it would be better to fail the operation in case of an offline change > > and to have the tool then move the re-connect to the normal connection > > establishing code. > > > > This should greatly simplify the driver logic … what do you think? Should > > we make our operations more complex to handle connection losses or should > > we fail fast and keep the logic simpler? > > > > Chris > > > > > > -- > *CEOS Automatización, C.A.* > *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* > *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* > > *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* > *Ing. César García* > > *Cel: +58 414-760.98.95* > > *Hotline Técnica SIEMENS: 0800 1005080* > > *Email: [email protected] > <[email protected]>* >
