Advice reqeusted to migrate MSR from Bare Metal to Container

[tunnus]

I have the following rule:

Use this to detect errors in Nibe uplink service, and every time updated data is fetched, a timestamp is stored. This triggered already yesterday, but re-triggered as I tried to manually recover this rule with a reset (hence there's no original "true as of xxx" time).

So as a clarification, service works now and timestamps are updated, but this rule does not "recover" (stays triggered / SET). Did also restart MSR during this situation, though it was not related to this.

The condition where there was no change (and rule was working correctly) lasted over 24 hours.

Running MSR 22179 on Synology Docker. Can PM relevant logs if needed.

[toggledbits]

You have "not" set on the outer group. The inside condition is false, so the group state will be true (not false).

[tunnus]

@toggledbits but that inside condition should have been true, it was "stuck" in a way, as I tried to explain. If you look carefully that previous screenshot, you'll see that the timestamp is newer than "false as of" time confirming this bug.

I did another MSR restart, but it didn't help. Then I added one second to "delay reset" & did reset the rule, and situation is resolved (for now):

[toggledbits]

The string displayed to the left of the "true/false as of" is irrelevant to me, because it is just a string. I have no idea what its source is or how it was generated. You haven't shown that work, so I have no basis on which to gauge it, and no basis on which to assume that the string displayed has any bearing on actual time and when, or useful in comparing to the other timestamps. I guess you have more you need to present to make your case here?

[tbully]

@tunnus - I think we're struggling with a similar issue. I came here to post a similar issue and saw your situation.

I'm still moving things over from Vera to stand alone MSR (With Home Assistant being my eventual controller). This rule worked great in Vera but not so much here. I'm basically just looking for this string to change every xxx seconds. I don't care what the string is. As long as it changes, I know that in this case, my SiteSensor is getting new data. However, it appears to not reset even though I see the string (time stamp) changing:

Here's another rule behaving the same way:

[toggledbits]

Both of you need to show all the work... where the strings are being generated and set, etc.

Edit: I'm moving my son to college, so I will not be available for the next few days.

[tbully]

I kind of knew you'd respond with that but I'm not sure what else to show. I'm sorry.

Congrats on the move. My twin daughters are just a few years away from that and I'm dreading it.

This is a SiteSensor coming from Vera. It generates strings depending on what's returned from the API call. In this case, I'm just looking at a timestamp response. 2022-08-10T17:12:06Z Other strings are temperature, humidity, wind info, etc. But "Value 8" is the timestamp of the last packet of data from my weather station. If it doesn't change, it means my Weather Station (or Wunderground, etc) has given up.

The other one is a LuupReload counter from Vera. Again, I don't care what the value is - just that it changed (in this case - incremented).

[tunnus]

I’ll try to reproduce this issue at some point, but my hypothesis is that if the value (string whatever) is static ”too long”, underlying code ”gives up” and stops to monitor it.

In my case there was a long maintenance break and didn’t receive new data for about 24 hours and hence timestamp remained the same.

Why this conclusion? Because so far this rule has worked fine (there hasn’t been long breaks getting data).

[tbully]

Thanks. I've just disabled those rules and gone back to Vera's Reactor for now. I'm not convinced is something I'm not translating from Vera to MSR....

I'm currently running: stable-22168-1f3a1cf1

[toggledbits]

@tbully said in "changes from" operator stops to detect change:

but I'm not sure what else to show. I'm sorry.

I'm back from my trip. I am asking you to show exactly what I asked for:

where the strings are being generated and set, etc

I think that's pretty clear, but I'll detail it out: that means, you show me the expression variable where the time is stored, and if the time is set by a reaction, you show me (all of) that reaction, and if it's in a rule, you show me (all of) the triggers and constraints in that rule as well.

[tunnus]

@toggledbits in my case timestamp is updated as follows (and I admit it seems bit of a hack overall, but it is what it is...)

Updated data along with time are fetched to g_txtResponse variable and then time is parsed separately to another g_UplinkStatus variable which is used to monitor that data feed is working

[tbully]

@toggledbits

Apologies for the delay. I was out last week. I promise I'm not dense. I just wasn't clear how much detail you wanted so I'll try again. I thought my explanation and screen shots would be sufficient:

Here's the SiteSensor Config in Vera (recipe below).

{
    "name": "",
    "author": "",
    "description": "",
    "config": {
        "RequestURL": "https://api.weather.com/v2/pws/observations/current?stationId=KMICANTO5&format=json&units=e&apiKey=XXXXX",
        "Headers": "Accept-Encoding: gzip",
        "Interval": "120",
        "Timeout": "30",
        "QueryArmed": "0",
        "ResponseType": "json",
        "Trigger": "err",
        "NumExp": "8",
        "FailMasterOnExpressionError": "1",
        "FailChildOnExpressionError": "1",
        "BlankChildOnExpressionError": "0",
        "Expr1": "response.observations[1]",
        "Expr2": "response.observations[1].imperial.temp",
        "Child2": "urn:schemas-micasaverde-com:device:TemperatureSensor:1",
        "Expr3": "response.observations[1].imperial.windSpeed",
        "Child3": "urn:schemas-micasaverde-com:device:GenericSensor:1",
        "Expr4": "response.observations[1].imperial.windGust",
        "Child4": "urn:schemas-micasaverde-com:device:GenericSensor:1",
        "Expr5": "response.observations[1].imperial.precipRate",
        "Child5": "urn:schemas-micasaverde-com:device:GenericSensor:1",
        "Expr6": "response.observations[1].winddir",
        "Child6": "urn:schemas-micasaverde-com:device:GenericSensor:1",
        "Expr8": "response.observations[1].obsTimeUtc"
    },
    "source": "20095",
    "version": "22234.1336"
}

[tbully]

Given this thread: https://smarthome.community/topic/455/replacing-sitesensor-plugin-vera-with-msr/34

Maybe I just turn this responsibility over to MSR and make life easier. It will have to be done at some point anyway (as Vera is going away)

[toggledbits]

I think you need to make sure the time is actually changing; I'm betting its not, because I think obsTimeUtc isn't what you think it is/doesn't work the way you think it does. Just because SiteSensor makes a request doesn't mean that time is going to change. The time you are putting into Expression 8 in SiteSensor is the observation time, that is, when the weather stats it is reporting were gathered by weather.com, not the current time of the SiteSensor request. It's very easy to imagine that it can be considerable time between observations (more than 600 seconds) even when SiteSensor requests are running every two minutes. If weather.com is only updating its own data every 30 minutes, then I would expect this logic to fail most of time, except once every 30 minutes (or whatever the actual time is between weather.com observations/refreshes of its own data), but certainly not give you what you want.

If you want the time to change every time SiteSensor makes a successful request, put time() into Expression 8 in SiteSensor.

[tbully]

@toggledbits
I have thought about that. But I just checked again. Value 8 updates (to the second) each time it successfully runs. This is the observation time from the weather station itself (the station at my home). This is important as it's that lack-of-update that I'm trying to detect. Otherwise, I would agree that time() would be sufficient.

Another interesting fact is that this rule/reaction works OK in the "Vera Instance" of Reactor.

[toggledbits]

OK... one more thing I noticed, hating to state the obvious but I can only react to what you give me... as shown, the rule is disabled.

Beyond that, I think you need to debug this using your Vera and the status view for the rule:

1. Open the rule's status view, so you can see each condition and its state and dependent values.
2. Open your Vera UI in a separate tab, and go to the SiteSensor's control panel, Advanced > Variables tab.
3. Modify the Value8 variable to anything else, and observe what happens to the displayed value and status in the rule status view. It should follow (the current value in the condition state should change to what you set it to on the Vera, and that should trigger the condition, carry up through the group inverted as programmed, etc.).
4. If the value changes and triggers the changes condition, make sure the rest of your logic is doing what you expect.

[tbully]

@toggledbits

Apologies for the silence. The work week got away from me.

While I wouldn't put it past me, the rule is indeed enabled.

I'm doing something similar to your suggestion in order to test.

1. MSR status up in one window (see screenshot)
2. In Vera console in another window, I disarm/arm SiteSensor. As you're aware, this causes a re-fire of the recipe.
3. I can then visual see the Value8 value change in the window.

Is that a good enough test or should I go further somehow? (e.g. manually modifying Value8) Is there a way to increase debug level so we can see the payload coming back from Vera to MSR?

[toggledbits]

Maybe good enough, but I prefer assigning unambiguous, easy-to-read random strings (alpha, beta, gamma, ...). Either way, the point is to make sure you see the string change to match what you set it to here (highlighted location):

What I'm going for here is a first level check: make sure the value is making it from the Vera to Reactor. I don't care about the logic state of the condition or any parent groups at this point, I just want you to confirm that the value shown changes immediately in Reactor when you change it on the Vera.

Oh, and by the way, please upgrade to latest and try it as well.

[tbully]

Sigh. So this is weird. I updated to the latest and no change.

I then took your advice and just was manually changing the Value8 variable in Vera from alpha to beta. It still didn't help. I finally took the 600 second delay out and noted that the set/reset started working. Put the delay back and all is good (I think).

I'll keep an eye on it. Thanks for sticking with me on this one.