full devices reset

[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.

[PerH]

It definately does. (work well, that is) Thanks!

[PerH]

Token lost again today..

The z-way-server.log seems to be about z-wave communication only, wonder if I can find traces of wtf is happening with the token somewhere as well?

[akbooer]

Is this exactly 7 days after it was refreshed?

[PerH]

nope. 9 days..

[powisquare]

Updated openLuup to v. 21.6.8 yesterday. I notice the z-way bridge has lost connection. and requires login. When I go to device/actions there is no way to enter credentials - only a login button.