Stop the MSR by an external switch on Hubitat.

[tunnus]

@toggledbits sorry, I tried to depict the problem in the first post as well as I could.

But yes, your test case models my case and now I'm baffled. I'll try to setup my test from a scratch and see what happens...

EDIT: replicated this case, no change. Local variables work nicely, but global expressions won’t update. Patrick, any logs I could provide to solve this?

Only difference I could think of (between my and your test setup) is that if response structures (array etc) differ just enough and code handles local & global expressions a bit differently.

[toggledbits]

The key here is that the response to the HTTP request has to change. If it doesn't, then the changes isn't going to work, and nothing will trigger the rule to evaluate and cause the other global variables to be updated. Remember that changes requires an actual change of the value, not just a fetch of the value and setting it (again) to what's already there... no change, no changes.

[tunnus]

@toggledbits what's strange here is that I only change this:

to this:

or vice versa, URL & other settings remain the same, local expression works, changes are immediately detected. And yes, response is really changing.

Here's the most current test rule:

(at the time of the screenshot, "-111.0" was the correct value)

The only time I get an updated/correct value (for the global expression) is when a global variable/expression is initialized (when it is empty), after that it remains the same.

Maybe this problem is unique to my setup.

[tunnus]

@LibraSun, @cw-kid & others, could you test if you can replicate this error I'm experiencing?

EDIT: I have another rule querying the same API, for a bit different values and that works fine even with global expressions, so reproducing the same error might prove to be difficult...

[wmarcolin]

@toggledbits, in your test proposal, when the HTTP Request fails, an error is generated and thus an Alert is displayed on the dashboard. Since this is an under-control situation, is it possible to inhibit this alert?

[toggledbits]

Depends on how you're doing the implementation. What's the error that's generated?

[wmarcolin]

@toggledbits I am referring to this error alert, generated when I interrupt the internet access, automatically the HTTP GET will fail, which is expected and I will give the necessary treatment. But I would like to not have this alert in the status dashboard, because as I mention it would be an expected problem, I don't need the alert.

Now of course this is no big problem, just exploring more possibilities.

[tunnus]

@toggledbits if you'd be willing to troubleshoot this issue further, I could provide you the whole response to this http request? But where is that response stored on the filesystem?

What seems to happen is that if my global expression/variable is empty, fresh data is initially stored to that, but subsequent queries are "ignored", data is not replaced.

In the log I can see new/fresh values, but for some reason this new data is not used:

2021-10-01T14:04:00.321Z <Rule:5:Rule.js:997> Rule#rule-ktc09w2v._evaluate() trigger state now false (was false)
2021-10-01T14:04:00.323Z <Rule:5:Rule.js:999> Rule#rule-ktc09w2v._evaluate() constraints state true
2021-10-01T14:04:00.325Z <Rule:5:Rule.js:1008> Rule#rule-ktc09w2v rule state now false, changed no
2021-10-01T14:04:00.548Z <Engine:INFO> Engine#1 reaction Nibe uplink SiteSensor<SET> step 0 HTTP request to https://192.168.XXXX:8443/rest/items?tags=nibe2vera&recursive=false succeeded (200 OK)
2021-10-01T14:04:00.552Z <Engine:5:Engine.js:1547> Engine#1 response type application/json
2021-10-01T14:04:00.556Z <Engine:5:Engine.js:1169> Engine#1 global set variable g_UplinkTest = (object) [ { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Control_HotWaterBoost", "state": "0", "stateDescription": { "pattern": "%.0f", "readOnly": false, "options": [  ] }, "commandDescription": { "commandOptions": [ { "command": "0", "label": "Off" }, { "command": "1", "label": "3h" }, { "command": "2", "label": "6h" }, { "command": "3", "label": "12h" }, { "command": "4", "label": "One time" } ] }, "editable": true, "type": "Number", "name": "NibeRESTAPI_Control_HotWaterBoost", "label": "Hot water boost", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Status_DegreeMinutes", "state": "-54.3", "stateDescription": { "pattern": "%.0f", "readOnly": true, "options": [  ] }, "editable": true, "type": "Number", "name": "NibeRESTAPI_Status_DegreeMinutes", "label": "Degree Minutes", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Ventilation_FanSpeed", "state": "72.0", "stateDescription": { "pattern": "%.0f", "readOnly": true, "options": [  ] }, "editable": true, "type": "Number", "name": "NibeRESTAPI_Ventilation_FanSpeed", "label": "Fan Speed", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Addition_Blocked", "state": "ON", "stateDescription": { "readOnly": true, "options": [  ] }, "editable": true, "type": "Switch", "name": "NibeRESTAPI_Addition_Blocked", "label": "Blocked", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_CprInfoEp14_CurrentComprFrequency", "state": "20.0 Hz", "stateDescription": { "pattern": "%.0f", "readOnly": true, "options": [  ] }, "editable": true, "type": "Number:Frequency", "name": "NibeRESTAPI_CprInfoEp14_CurrentComprFrequency", "label": "Compr. Frequency", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Status_OutdoorTemp", "state": "10.9 °C", "stateDescription": { "pattern": "%.0f", "readOnly": true, "options": [  ] }, "editable": true, "type": "Number:Temperature", "name": "NibeRESTAPI_Status_OutdoorTemp", "label": "Outdoor Temp.", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Status_AlarmInfo", "state": "NULL", "stateDescription": { "pattern": "%s", "readOnly": true, "options": [  ] }, "editable": true, "type": "String", "name": "NibeRESTAPI_Status_AlarmInfo", "label": "Alarm Info", "tags": [ "nibe2vera" ], "groupNames": [  ] }, { "link": "https://192.168.XXXX:8443/rest/items/NibeRESTAPI_Status_HotWaterTop", "state": "46.3 °C", "stateDescription": { "pattern": "%.0f", "readOnly": true, "options": [  ] }, "editable": true, "type": "Number:Temperature", "name": "NibeRESTAPI_Status_HotWaterTop", "label": "Hot Water Top", "tags": [ "nibe2vera" ], "groupNames": [  ] } ]
2021-10-01T14:04:02.173Z <Engine:5:Engine.js:1367> _process_reaction_queue() wake-up!
2021-10-01T14:04:02.200Z <Engine:5:Engine.js:1328> _process_reaction_queue() running task 1179 { "tid": 1179, "id": "rule-kt9u8aur:S", "rule": "rule-kt9u8aur", "__reaction": [RuleReaction#rule-kt9u8aur:S], "next_step": 2, "status": 0, "ts": 1633097040135, "parent": --null--, "__resolve": --function--, "__reject": --function--, "__promise": [object Promise], "attempts": 1 }
2021-10-01T14:04:02.201Z <Engine:NOTICE> Resuming reaction Nibe uplink SiteSensor<SET> (rule-kt9u8aur:S) from step 2
2021-10-01T14:04:02.204Z <Engine:5:Engine.js:1537> Engine#1 request header accept: application/json
2021-10-01T14:04:02.205Z <Engine:5:Engine.js:1539> Engine#1 reaction rule-kt9u8aur:S step 2 request url https://192.168.XXXX:8443/rest/items?tags=nibe2vera2&recursive=false data { "method": "GET", "timeout": 15000, "size": 8192, "agent": [object Object], "headers": [object Headers] }
2021-10-01T14:04:02.208Z <Engine:INFO> Nibe uplink SiteSensor<SET> all actions completed.
2021-10-01T14:04:02.209Z <Engine:5:Engine.js:1332> _process_reaction_queue() task returned, new status -1; task 1179
2021-10-01T14:04:02.212Z <Engine:5:Engine.js:1367> _process_reaction_queue ending with 0 in queue; none delayed/ready; waiting

(and then it continues with another http request in the same reaction, 2 s delay in between)

[toggledbits]

@tunnus said in SiteSensor migration:

What seems to happen is that if my global expression/variable is empty, fresh data is initially stored to that, but subsequent queries are "ignored", data is not replaced.
In the log I can see new/fresh values, but for some reason this new data is not used

You're going to have to describe this in more detail.

[tunnus]

@toggledbits I'll PM you relevant logs

[toggledbits]

Make sure you test with 21275 first.

[tunnus]

@toggledbits will do