# Alarm on (modbus TCP) device status **URL:** \ **Category:** Ignition\ **Tags:** ignition81, modbus\ **Created:** [March 26, 2024, 11:39am UTC](https://forum.inductiveautomation.com/t/alarm-on-modbus-tcp-device-status/87888 "2024-03-26T11:39:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Rutger\_Van\_Aelst](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rutger_van_aelst/32/54459_2.png) [@Rutger\_Van\_Aelst](https://forum.inductiveautomation.com/u/Rutger_Van_Aelst)\ **Post date:** [March 26, 2024, 11:39am UTC](https://forum.inductiveautomation.com/t/alarm-on-modbus-tcp-device-status/87888/1 "2024-03-26T11:39:54Z")
Hi all, does anyone have advice on what the best way would be to generate an alarm when a device is disconnected? Specifically in this case I'm monitoring Modbus TCP devices. I tried generating an alarm when the status (from the device system tag) is different from "Connected", but I notice even when I unplug the ethernet cable it switches constantly between "Connected" and "Disconnected". ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/2/82c337179d132797bbe2201cba8ed2a64e62f620.png) This results in a endless stream of alarms as long as the device is disconnected: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/9/09a2115bfa5f6ff41666e745ffc7129e351d3fe8.png) Seems like it would be a very common thing to do but I can't seem to find a conclusive answer on the forums or in the documentation. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 26, 2024, 11:46am UTC](https://forum.inductiveautomation.com/t/alarm-on-modbus-tcp-device-status/87888/2 "2024-03-26T11:46:48Z")
I would use an expression tag that checks the quality of one of the subscribed tags. Alarm on bad quality after a short delay. It's common to also use such a tag, if configured to be true on good quality, to be the control for a driven tag group, to which all **other** tags in that device are assigned. (With the driven group's "slow" pace set to zero--disabled.) This will greatly reduce log spam. ---
**Author:** ![Rutger\_Van\_Aelst](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rutger_van_aelst/32/54459_2.png) [@Rutger\_Van\_Aelst](https://forum.inductiveautomation.com/u/Rutger_Van_Aelst)\ **Post date:** [March 26, 2024, 8:29pm UTC](https://forum.inductiveautomation.com/t/alarm-on-modbus-tcp-device-status/87888/3 "2024-03-26T20:29:47Z")
Thanks for the insights Phil, I'll probably implement it this way. I was hoping there would be a more "standard" way to handle this, it would seem like something that would benefit practically every project. I'd find it odd that we have to identify a subscribed tag to be used as a connection check for every type of device. It seems to me that either this system tag, or the diagnostics tags on the Ignition OPC UA server were meant for this. I must be doing something wrong here. These are the device status system tag and 3 device diagnostic tags from the OPC server, all for the same Modbus TCP device, the cable is unplugged at all times during this clip: ![VirtualBoxVM_2POQ73EJ1O](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/c/ec45903f5d4aa8da77d8bd0a3d303ea4879b5af8.gif) Any idea what could be going wrong here? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 26, 2024, 8:44pm UTC](https://forum.inductiveautomation.com/t/alarm-on-modbus-tcp-device-status/87888/4 "2024-03-26T20:44:34Z")
When there is a problem, the driver tries to reconnect, regularly. If it happens only occasionally, Ignition will "ride through" the brief breakage. But gives the wrong result for your case, where the breakage isn't going away.