openweather plugin ?

[a-lurker]

Just to complicate things: in addition to the 3em pro - I've got a shelly pro em 50 turning up in the mail.

[akbooer]

I’ve rationalised a lot of the ShellyBridge handling of Gen 2+ devices, so this shouldn’t be too much of an issue.

[a-lurker]

I tried out the new update: "Development Branch: 2024 Release 4.5". Nothing too badly broken so that's good. I notice the H&T devices now have new variable names ie humidity/0/rh and temperature/0/tC, etc. These no longer show up in AltUI or console at Home-->Devices. Likewise with the 3em pro: em/0/a_voltage, etc

No doubt a work in progress but the forward slashes are a bit problematic eg they can't be part of a whisper filename.

[akbooer]

Delimiters are always a problem. I tried initially with ‘:’, but UPnP already took that. However, it’s not intended that you use these directly; they are simply transcriptions from the MQTT topics. As with other Shellies, the key variables get copied to the MiOS equivalents, possibly in child devices, so that everything works.

I am making progress with the RGBW, and remember just how much I hate the way MiOS tries to handle them… and on top of that, AltUI has its own quirks.

[a-lurker]

Lots of work done refactoring things - should "Eclipse" the older versions. Code still working here - thank you.

[akbooer]

Yes, thanks.

BTW, "Generic status update over MQTT" should not need to be ticked, now.

You will also have seen that you can use luup.openLuup.pretty() directly.

[a-lurker]

I've got something about pretty printing here. No doubt in my writings, I have made a few errors here and there but that can happen. OK on the "Generic status update over MQTT" - I'll fix that in the paragraph immediately above here.

[akbooer]

Ah, OK, that’s great.

Whilst on documentation, the bit on Quick graph view is incorrect where it says:

”Uses Google Charts, so an internet connection is required..”

This used to be the case, but now it’s all local SVG, so no external connection needed.

[a-lurker]

Doco corrected.

[a-lurker]

Had a look at the latest development code. Got this:

2024-04-20 18:51:28.519   openLuup.userdata:: [9111] LuaView (GitHub.master)
2024-04-20 18:51:28.519   openLuup.userdata:: [9281] Virtual HTTP Devices (GitHub.master)
2024-04-20 18:51:28.519   openLuup.userdata:: [4226] Sonos (GitHub.v2.0)
2024-04-20 18:51:28.519   openLuup.userdata:: ...user_data loading completed
2024-04-20 18:51:28.519   openLuup.init:: running _openLuup_STARTUP_

2024-04-20 18:51:28.525   scheduler.context_switch::  ERROR: [dev #0] ./openLuup/luup.lua:1103: attempt to index field '?' (a nil value)
2024-04-20 18:51:28.525   openLuup.init:: ERROR: ./openLuup/luup.lua:1103: attempt to index field '?' (a nil value)

2024-04-20 18:51:28.525   openLuup.init:: init phase completed

Had to get the house back up and running, so we could watch the TVeee.

Commented out some code:

local function log (msg, level) 
  local dno = scheduler.current_device()
  -- local mute = devices[dno].attributes.log_level    -- 2024.04.12  add "log_level" device attribute
  local mute = "something"
  if mute ~= "off" then
    logs.send (msg, level, dno) 
  end
end

Could look further but had to get the house back up and running, so we could watch the TVeee. So best I can do currently!

[akbooer]

Ouch, sorry!

Away from my development system for a couple of days, but will dig into it when back.

Have to find out why I didn’t run into this myself when testing (I do, actually, test things!)

[akbooer]

@a-lurker

Could you try latest development v240426 to check this is fixed.

Thanks and, again, apologies.