The working button email shows the panel can send mail, so leave the mail settings alone. The silent event points at its trigger chain: the address it reads, whether it acts on the state or on the change into it, and any second condition gating it. Test those in order with one controlled true-to-false transition after a download.
A panel that sends email fine from a button and never sends from an event has no mail problem. The button press runs the email action directly, and that message arrives, so the server, the login and the network path are good. What fails is the chain between the input and the action: the address the event reads, whether it acts on the state of that address or on the change into it, and any other conditions sitting on the same event. Work those three in that order, then run one controlled test with a fresh transition. The same split shows up in file transfers, where the transmit test passes but event FTP never sends the file.
What the working button proves
A button on every screen mails the maintenance team on each press, and a second button mails the time, the date and the shift's gas usage with live values in the body. Two conclusions follow. The panel's mail transport works, so leave the server address, port 587 and the login exactly as they are. And the panel can build an email body from live tag values, so the event can carry the same data.
Your one comparison job at this stage is action against action. Open the event's email action and the button's email action side by side, and match recipients, subject, message and sender field for field. A wrong recipient on the event looks identical to a dead event from the inbox. If the button email ever stops too, that is transport, and the fix there is to use a relay the panel can talk to. The panel maker's own email setup tutorial walks through rebuilding the mail configuration from zero, so use that document if the transport itself ever needs rebuilding.
Symptoms and what each one points to
- The button email arrives within 2 minutes of the press, the event email never does. Transport and the email action type both work. The fault sits in the event's conditions or its trigger setting.
- The Data View shows X171 false and nothing sends. The panel sees the input state. What is unverified is the address the event references and whether the event wanted a change it never received.
- The event fired once at commissioning and never again. The input likely sits false from startup, so a trigger on the change into false sees nothing new.
- An email arrives with a blank or wrong body. The event's action and the button's action differ. Copy the working action over.
- The button with time, date and the gas counter works. The panel composes mail with live tag values, so the event can carry the same data.
Check the address the event reads
On a C-more panel the events live in the Event Manager Database, opened from the Main Menu under Database, or from the Database group on the Function tab. Each event watches conditions in the panel and runs its action when the conditions are met, and the panel's Event Manager Database reference document describes exactly that loop.
Select your event and read the tag in its condition line. Then read the address in the Data View row that displays the input. The two must match character for character. A one-character slip, X170 against X171, keeps the screen looking right while the event watches a point that never changes. The Data View answers one question, the state of the address it lists. The condition line answers the other, which address the event reads. If they disagree, put the Data View address into the event and download, which takes about 1 minute on a panel already on the network.
State or change: what the trigger acts on
Event triggers come in two kinds. A level trigger acts while its condition holds: input false now, act now. An edge trigger acts on the change into the condition: act once, at the moment the input goes false. The two behave the same right up until the input is already in the fault state when the panel starts, and that is the case behind this symptom.
Download the project while the fault relay is already dropped, and X171 sits false before the event begins. An edge-triggered event receives a steady false with no new transition, and the Data View shows false the whole time because it shows state. Open the event and read which rule its trigger uses, then decide what you want: one email at fault onset is the edge rule, a notice that tracks the fault is the level rule. If you need the level rule to repeat while the fault persists, read how your version handles repetition in its documentation before you design around it. Holding the input false for 10 minutes to find out is a bad way to learn it.
Check the other conditions on the event
One event can combine up to 4 tag conditions with boolean logic, per the panel maker's event manager documentation. An event set up as X171 false AND line running stays silent every hour the line is down, no matter how many faults land on the input.
Open the event and read every condition, then check each of those tags in the Data View. In a safe 15-minute test window, strip the event to the single fault condition and download. If the email arrives now, bring the other conditions back one at a time, downloading and testing after each. The condition whose return silences the email is the blocker: fix its logic, or accept the gate and tell maintenance when notifications are armed.
Example: the X171 fault relay, one download and two transitions
Inputs. Input X171 is wired to a fault relay: relay picked up means healthy and X171 reads true, and any fault drops the relay so X171 reads false. The event holds 1 condition on X171 and 1 email action. Transport is already shown working: a button on every screen mails maintenance, and a second button mails the time, the date and the shift's gas usage in cubic feet. The event has room for up to 4 conditions, so a forgotten gate is possible.
Rule. An event that acts on the change into false sends one email per true-to-false transition the panel sees after the event starts running. Emails = transitions seen × 1.
Arithmetic. Fault already present at download: X171 is false before the event starts, so transitions seen = 0 and emails = 0 × 1 = 0, while the Data View reads false the whole time. Controlled sequence: force the relay on so the Data View reads true, download the project, then drop the input once, giving transitions seen = 1 and expected emails = 1 × 1 = 1, arriving within 2 minutes. Confirmation: restore true, drop false again after 1 minute, giving 2 transitions and 2 expected emails.
Decision. Two emails from two transitions passes the chain, and you commission with the input true every time. Zero emails from two clean transitions, with the address already matched, moves the case to the gating conditions and the action comparison. One clean transition after the download is the pass mark.
The controlled test, step by step
Never trip a live process fault to test a notification path. Force the input or the relay into each state from a safe condition, or use the approved simulation.
- Put the process in a safe state and agree a 15-minute test window.
- Force the fault relay on and confirm the Data View reads X171 true.
- Download the project with the event in it.
- Drop the input false once. One email should arrive within 2 minutes at the inbox the button uses.
- Restore true, confirm it in the Data View, then drop false again. Two clean runs out of two is the pass mark.
- Log the time, the forced state and the result for every attempt, each attempt 1 minute apart.
If it still sends nothing
With the address matched, the transition fresh and the event stripped to one condition, two items remain. First, copy the button's email action into the event, recipients and message included, download, and repeat the two-transition test. Second, confirm the edited event is inside the project you actually downloaded, and repeat. If the button still delivers while the event stays silent after 2 more clean transitions, stop editing. Collect the panel model, the project version, the event's full configuration, the button's action for comparison and the test log, and take the package to the panel maker's support.
Keep the button until the event passes
The button needs a person to press it, so tell maintenance that automatic fault mail is out of service until the test passes twice. Once it passes, the standing arrangement is a verified chain: the relay changes, the panel reads X171, the event references that same address, the trigger rule matches the intent and the action matches the button's. If the team answers texts faster than inbox mail, an alarm email can also go to a phone as a text message.
Recommendation: While the button email keeps arriving, change nothing in the mail settings. Spend the work on the event: match its tag address against the Data View character for character, run the true-download-false test for a fresh transition, then strip the event to its one fault condition and bring the others back one at a time. Touch the mail configuration only if the button email stops too.
Questions
Why does the button email arrive but the event email never send?
The button runs its email action the moment it is pressed, with no conditions to evaluate first. The event has to see its own conditions met on the addresses it references. A wrong tag address, a trigger waiting for a change that only ever saw the steady state, or a second condition sitting false will each stop the event while the button keeps working.
Why would the event fire once and never again?
An event acting on the change into false sends one email per healthy-to-fault cycle. If the input never returns true between faults, the next drop is a steady state and the count stays where it was. After every download, test both directions: force true, drop false, force true again, and expect one email per clean drop.
What should I collect before contacting the panel maker's support?
The panel model, the project and firmware versions, the event's full configuration with every condition listed, the working button's email action for comparison, and a test log showing each attempt's time, the forced input state, the Data View reading and whether the email arrived. A support engineer can reproduce the case from that list in one pass.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.