Hey Mark,
same probleme here since tuesday morning.
I wanna try it with the REST API in the next days.
Hi. I contacted mobile-alerts and they replied. They are aware of the problem and have alerted their service provider.
I think this is the second time I have seen issues with the sensor web page. This time the fix seems slower to come. Too slow. They just said use your phone app to view your data. Hmmmm.
So, like you I am moving more of the openhab sensor data collection over from webpage caching method to REST API. I have a mix of both methods.
However, API isn’t available for all sensor types. I should complete today a check of the list of supported sensor types that’s in the mobile-alerts API info doc. So, far it seems up to date. I will post later which devices and which cannot use the API method.
Which brings me to an interesting point. Despite the web server fail the app continues to work for all device types.
So, it would be good to know how the app is getting the data for device types which are not supported for API. I don’t have the skills to sniff around and so I hope someone here has and the motivation, or maybe one the contributors to the mobile-alerts github documentation. 
I would be very glad about such a list.
Unfortunately I do not know how the app is getting the data, but yes my app still works too.
mobile-alerts API documentation
Device type is indicated by first two characters of the device ID
Listed API supported devices.
WInd, Rain and Pro devices
01 Temperature with probe . not tested
08 Rain gauge. OK
09 Temperature/Humidity with probe. OK
0B Wind anemometer. OK
0E Temperature/Humidity … not tested
Tested and found to be unsupported:
02 Temperature
03 Temperature/Humidty
11 Temperature/Humidty station
12 Humidity station
So, as far as I can tell the above linked doc appears complete
Update…sensor web page is working on and off
https://measurements.mobile-alerts.eu/
but I am still going to move my pro sensors to API.
If you are using the API method and update your openhab to 2.5.2 then beware the following:
edit…
I improved the API rule to better capture when the REGEX fails and to track how long has elapsed since a sensor was ‘last seen’. I will post the rule code if anyone is interetsed.
I found for the rain sensor the rainfall ammount value dissapears in the API return result after some time but returnsagain if there is any rain. It could also be related to the recent poor performance of the sensor web server. This disappeared value causes the REGEX to fail and when it fails it retruns the full API string (not null as I had previously and erroneously assumed)
Hey Mark,
is it possible to use the same way to get the battery level?
Yes, e.g.
"lowbattery": false
The http measurement web page has been performing badly for sometime now. The web server seems to have stopped for http requests. I see 403 error. The app seems unaffected and the REST API is still working but that doesn’t work for non pro sensors.
Is anyone else having trouble with the http cache method?
Yes, I had couple of non professionell sensors running in that way. Until yesterday, when mobile alerts stopped the site. I couldn’t find any comment from m.a. about this. Strange!
I sent them an email. They usually reply. I will post back if they do.
My openhab log was filling up with errors! So, I uninstalled the http binding to stop them.
Thanks, also for your hint.
Yes, it dont work since few hours.
I received a support ticket number but no update yet. The home page now works but on entering a phone ID there is an sql exception
Got a reply
There was a temporary problem which we fixed, and the site is usable again as usual.
The web page seems to be working again.
but I have noticed for sometime now an increasing unreliability of the service
M
Now it works fine
Hey Mark, do I have to use Javascript transformation?
I use it for temperature, etc.
yes, i use js regex transfomation.
I impoved the error handling to stop my log filling up when the internet is not available or the mobile alerts server is having problems.
First step was to move the HTTP updating of items from the items definitions and into a new rule file.
From this
Number MobileAlertsTHSensorTemperature "Bedroom [%.1f °C]" <temperature> (gMobileAlertsInsideTemperature) //{ http="<[sensorCache:300020:JS(getTHSensorTemperature.js)]" }
I just // commented it out for now.
To this:
item
String MobileAlertsHTTPCache "Mobile-Alerts HTTP cache" <text> { http="<[sensorCache:300000:REGEX((.*))]" } // cache checked every 5mins.
rule trigger
Item MobileAlertsHTTPCache received update
items updated in rule
newval = transform("JS", "getTHSensorTemperature.js", MobileAlertsHTTPCache.state.toString)
MobileAlertsTHSensorTemperature.sendCommand(newval)
Now thats done I can apply conditions to the rule before the items are updated.
I check if the cache contains my phone number, as it normally does, before running the items updates eg if server times out etc and I use try + catch to catch exceptions etc when the HTTP binding fails. eg no internet access ( I believe this might be fixed in a new bdining for OH3)
Like this:
val String errorcheck = transform("JS", "checkCache.js", MobileAlertsHTTPCache.state.toString)
if (errorcheck == 'Phone ID 123456789') {
........item update code
}
else {
logError("Error", "Mobile-Alerts HTTP cache has no phone ID")
logError("Error", " Mobile-Alerts cache = " + MobileAlertsHTTPCache.state.toString)
}
Transform for this is:
(function(i) {
var re = new RegExp('(Phone ID 123456789)');
var out = i.match(re)[1];
return out;
})(input)
In the case when there is no internet connection, eg router reboot, I enclose all the rule code with :
try {
........all code
}
catch(Throwable t) {
logError("Error", "Mobile-Alerts HTTP cache rule error = " + T.toString)
}
I do the same for the API method rule and catch the exceptions and check if API return is normal, only this time looking for the string “sucess” message in the returned API
if (errorcheck == '"success": true') {
Transform:
(function(i) {
var re = new RegExp('(\"success\": true)');
var out = i.match(re)[1];
return out;
})(input)
Notes:
I am not sure if parseFloat(out) is really needed as used previously in the transforms for extracting temperatures etc but it will cause a problems when extracting strings with NaN returned. So, its just return out.
Results:
Router reboot test:
API
2020-10-17 09:40:47.927 [ERROR] [eclipse.smarthome.model.script.Error] - Mobile-Alerts API success check failed
I also log the curl output even if there is an error to see what is in there when it errors and will turn this off later.
HTTP binding
2020-10-17 09:38:53.309 [ERROR] [org.openhab.io.net.http.HttpUtil ] - Fatal transport error: java.net.UnknownHostException: measurements.mobile-alerts.eu
2020-10-17 09:38:53.311 [ERROR] [ab.binding.http.internal.HttpBinding] - No response received from 'sensorCache'
Hey Mark,
thank you,
Can you post aour regex?