full devices reset

[rafale77]

@DesT I am pretty sure that, like me, you didn't flag the token as permanent. I thought I did too as it was showing so on the UI but it's not how it works. See my post above.
I have never seen an expiration since.

@rafale77 said in Z-way token Expiration:

Well I think I figured it out: When going into the smarthome settings, you have to actually click on the "No Expire" box in order to make that token never expire. Otherwise it expires after one week.

[DesT]

Ahhhhhhhhh even if it's marked as No expire, you need to click on it!

[rafale77]

Yup, It is not a "mark" It is a button allowing you to set it as "no expire".

[PerH]

Well! I did push that button, and it still expired.. mabye flag this to @PoltoS then..

[rafale77]

Need to make sure that it is the token issued to openluup and not to your browser. There should be as many as login sessions you have opened in the past week. Then you need to figure out whether the "no expire" indicator is actually on or off. It isn't the most intuitive.
Given my experience with it, it works perfectly fine so I doubt there is a problem with the z-way.

[PerH]

i think i was, the token i put "no expire" on had the name "LuaSocket 3.0-rc1"..

Its definately not intuitive, no.. and you may find out that you have to push the button, but you also have to press "save" on what seems to be the table of settings above the connection table.. well, we'll see if it sticks this time!

[PerH]

It sticked for over a month, now i'm suddenly thrown out again.. @akbooer: I see in the log that the bridge knows its not logged in (says so in the reply to commands), could you set a variable for this, so reactor can be set up to notify me when this happens?

Seems to be an issue on the z-way side..

[rafale77]

That's very weird. Mine has not expired in 8 months. Is the token still in the bridge variable? I don't believe z-way resets it (based on my own experience)

No kidding. See my screen as of today:

[PerH]

I'm pretty sure it was there, and there was still "not logged in" in the log.. two days since last luup reload (added some sensors)..

[akbooer]

@perh

I’ll look at setting a variable to flag this condition, but like @rafale77 i haven’t seen this happen myself.

[akbooer]

Further to your request for a variable flag, there already is one, of course...

...if DisplayLine1 shows "Login required", then it's lost the token.

[PerH]

I'm pretty sure it didn't, and "commfailure" was zero as well? Thats why I went to the openluup log to find out what had happened.
I'll see if i can reproduce this state..

[PerH]

Confirmed. If I remove the active session for AltUI in Z-Way, i get this situation.

Openluup log:

2021-01-13 16:51:01.685   luup_log:198: ZWay: http://127.0.0.1:8083/ZAutomation/api/v1/devices
2021-01-13 16:51:01.686   luup_log:198: ZWay: Not logged in
2021-01-13 16:51:01.686   luup_log:198: ZWay ASYNC callback status: 401, #data: 13
2021-01-13 16:51:02.722   luup_log:198: ZWay: http://127.0.0.1:8083/ZAutomation/api/v1/devices
2021-01-13 16:51:02.722   luup_log:198: ZWay: Not logged in
2021-01-13 16:51:02.722   luup_log:198: ZWay ASYNC callback status: 401, #data: 13

No visible "not logged in" in GUI, and commfailure is 0?

[akbooer]

Yes. It’s only set at startup.

[PerH]

Ok, and to update DisplayLine1 when the openluup log is told "not logged in" should be an easy fix? I'll see if i can do it myself.

[PerH]

@akbooer, Is this the correct way to get DisplayLine updated if 401 is replied for a command?

Line 1761 in L_Zway2.lua:

  function _G.ZWay_async_callback (status, response)
    local delay = POLLRATE
    debug ("aync callback size: " .. #(response or empty))
    if status == 200 and response then
      local d = json.decode (response)
      local vDevs = d and d.data and d.data.devices
      if vDevs then
        updateChildren (vDevs) end
        --        delay = POLL_MINIMUM end                    -- yes, ask for another one soon...
        --        init = ''                                   -- ... without initialising data version
    elseif status == 401 then
	setVar ("DisplayLine1", 'Login required', SID.AltUI)
    else
      luup.log (log: format (status or '?', #(response or '')))
    end
    luup.call_delay ("ZWay_async_request", delay, '')    -- schedule next request
  end

[akbooer]

There's a few problems introduced here:

• there's also a synchronous request which perhaps need to be changed as well
• you've lost the output to the log in the case of 401
• it doesn't change the CommFailure variable or device status

Although I suggested it as a quick-fix, I don't think that useing the DisplayVariable is a particularly good way of flagging the error to a scene trigger (CommFailure would perhaps be more appropriate.)

Is this still an ongoing issue for you (ie. are you losing the credentials on a regular basis?)

[PerH]

No, haven't seen it since i mentioned it here.
I agree that commfailure should be set, and as long as something can tell me why shit stopped working without me going into AltUI (cursing), i'm happy.
If this is a viable way to do it, i'll use commfailure instead, and copy the log() line to the elseif and to the sync function.

The reason why the line drops should offcourse be addressed, but I think this is an important feature nevertheless, as there might be bugs in z-way and it seems to take a while between updates there..

I don't think i've had a single luup reload by the system since I was running Vera..

[akbooer]

@perh said in Z-way token Expiration:

If this is a viable way to do it, i'll use commfailure instead

No, it’s not sufficient to do that, since device status and last failure time will not be set.

You need to use luup.set_failure()

http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_set_failure

There need to be a few more changes to the ZWay module in the plugin too.

I’ll post a new version shortly, so that it’ll be in the baseline.

[akbooer]

ZWay development branch v21.1.19 has a fix.

As well as setting CommFailure, it also sets CommFailureTime, and the internal device status, which turns the plugin's device banner red on both AltUI and the openLuup console interfaces.

As I've said many times, this whole plugin was just a prototype and it seriously need rewriting to improve maintainability... but, nevertheless, it does work quite well.