B4043 battery alarm on local HTTP api

[broadstairs]

Mark I just thought I'd try my live system on the local HTTP api using my GW2000. On restarting CMX I suddenly got a low battery alarm and a message saying it could not find PHP switching back to TCP none of these errors show.

20241125-112449.zip

Stuart

[mcrossley]

The "php" is what is configured in the "action" field of the alarm - Cumulus tries to execute it.

The low battery is being cause by your WH40, it is reporting battery=0, which could be a flat battery, or could be that you have an old model that doesn't report battery state! The next release of Cumulus contains a fix - it ignores 0 values from WH40's.

[broadstairs]

Mark this only happens using the Local HTTP API. The PHP in action works together with the parameters to fire off script to send an alert to my phone via Pushover and again this works using the TCP api. I've had no reports of low batteries now for ages using the TCP api unless genuine and the script again has worked fine using the TCP api for months. This is the first time I've tried the HTTP api with my GW2000. I just ran the script manually from the CMX directory and it worked perfectly.

It is interesting that my GW1200 running with the latest beta does not show any of these errors!

Yes I do have an old WS40 which does not show valid battery but it does show a value

Stuart

[broadstairs]

I've just checked the HTTP api data returned by my WH40 on both GW1200 and GW2000 and it shows a zero for battery, however on the TCP api they both show a value equivalent to 1.6 volts despite this WH40 being an old one which does not send battery data!

Stuart

[mcrossley]

Yes, on the TCP API Ecowitt fudge a dummy voltage - they don't on the HTTP API.

Does it need the full path to PHP executable? It will if PHP isn't on the path for the user running Cumulus MX.

[broadstairs]

No PHP is in the system full path for all users so it works without the path details. This has been working OK on the TCP api on the GW2000 (build 4053) with exactly those details since I first installed it with no issues at all.

Stuart

[mcrossley]

I think you will need to add the full path. CMX does a check for file exists before trying to run it.

I'll see if there is a better way of doing this.

[mcrossley]

There isn't really (you would have to manually search the whole of the user path for the file).

So, I'll remove the file exists check and trap any File not found exceptions.

[broadstairs]

Mark this is driving me dolally! I tried adding the full path to php and it still says it cannot find the program, I tried a symlink in the CMX director as well but still no go! All this using the TCP api so why it no longer works is very confusing. I tried to ad full path to both the php and the script it points to and then it does nothing at all, no messages when it should trigger.

Stuart

[broadstairs]

OK so made some progress. I've change the way I am doing this now. I have made the script executable with the hashbang for PHP at the start so it can be executed and then specified that as the action item with the quoted message text to be sent as the parameter. That now works but only seems to work once for the alarm I'm forcing (wind gust over 2mph!) and then only after a restart, this is only set as notify and no email or latch. Just tried another restart and yes this time both Pushover message and having set email this time it also worked happened but again only once!

Stuart

[mcrossley]

The file exists checks were added in v4.1.3 b4028, I've changed them for v4.3.0

So, it triggers on start-up when the wind is above 2 mph, but does not trigger again?

Has the wind dropped below 2 mph and then gone above 2 mph to cause it to trigger again? Without a latch period, the alarm will not reset until the trigger condition becomes false.

[broadstairs]

I think I need to understand how latches work. I assumed that a latch meant it did not trigger again for that number of hours so if not set to latch it would trigger everytime it matched, at least that's what I intended. Am I correct?

Stuart

[mcrossley]

Sorry, my bad. You are broadly right.

Latched alarms may trigger again straight away if the trigger value dips under and back above the trigger value.

Latched triggered alarms are checked every 10 minutes, on the clock 10 minutes. If the value is below the trigger level at that point the alarm is cleared ready for triggering again.

User alarms are evaluated every minute (10 seconds past the clock minute) to see if they should be set or cleared.

[broadstairs]

Mark I think I've got it sorted now and understand how latching works. Also I suspect the issue with PHP was not that it could not find PHP but PHP could not find the script I referred t in the action parameters. The reason I think is that this is running as a service and even specifying the full path to PHP and the script did not work.

So I think the way this needs to work where CMX runs as a service is to make the script executable with the correct hashbang (shebang) to refer to the correct interpreter (PHP, Python etc) and then place the script including the full path in the action column and any relevant parameters only in the actions params column. This from my testing definitely works fine when running as a service. In fact I would recommend to always run like this whether a service or not. My old method only works when running directly from the CMX directory.

Stuart