openweather plugin ?

[Buxton]

@akbooer I used openluup json. I tried dkjson, but there was no change in effect.

[Buxton]

@akbooer Yes, that should work. However, the LWT MQTT specification calls for a standard message, so a tasmota upgrade could change the text message to a json message. Is there a way to test the message for a non-json string, and then filter accordingly. I fear the hardcoded flags will inevitably break....

[akbooer]

Yes, I thought of doing it that way. A simple check for a leading [ or { should be adequate.

This is the one thing I don’t like about Tasmota (as mentioned a while ago) … no real standards.

[akbooer]

OK, so here's what it will be now, a hybrid of our approaches...

  local valid = {SENSOR = 1, STATE = 1, RESULT = 1, LWT = 1}    -- thanks @Buxton for LWT as text message
  
  if not (tasmota and valid[mtype]) then 
    _log (table.concat ({"Topic ignored", topic, message}, " : "))
    return 
  end
  
  local info = json.decode (message) or {[mtype] = message}   -- treat invalid JSON as plain text

[Buxton]

@akbooer Awesome. Cool lua magic using the exception return with "or". That should cover all text messages that are topic filtered.

[Buxton]

@akbooer Can I ask you for one more addition. I'd like to be able to set tasmota prefixes and suffixes via lua startup. Something like:

attr ("openLuup.Tasmota.Prefix", "tele", "tasmota/tele","stat")
attr ("openLuup.Tasmota.Topic", "SENSOR", "STATE","RESULT", "LWT")

You'd also need to change the upper case error check on the topic as some of the full topic suffixes are not all in upper case:

local tasmota, mtype = tasmotas: match "^(.-)/(.+)"

[akbooer]

@buxton said in openLuup: Tasmota MQTT Bridge:

I'd like to be able to set tasmota prefixes and suffixes via lua startup.

Try the latest development version (21.6.12b)

A tiny syntax difference from your suggestion, you need to write...

attr ("openLuup.Tasmota.Prefix", {"tele", "tasmota/tele", "stat"})
attr ("openLuup.Tasmota.Topic",  {"SENSOR", "STATE", "RESULT", "LWT"})

[Buxton]

@akbooer After updating to the lastest development version (21.6.12b), I did a direct copy and paste of the above attr code into startup lua, and it appears that openLuup hangs on the ipairs iteration, because the ipairs statement is seeing a string instead of a table. I was then able to boot openLuup by removing the "or" clause :

--local prefixes = config.Prefix or {"tele", "tasmota/tele"}       -- subscribed Tasmota prefixes
  local prefixes = {"tele", "tasmota/tele"}       -- subscribed Tasmota prefixes
  for _, prefix in ipairs (prefixes) do
    luup.register_handler ("Tasmota_MQTT_Handler", "mqtt:" .. prefix .. "/#", prefix)   -- * * * MQTT wildcard subscription * * *
  end

The topic table has the same problem.

I was able to see the error message when using "./openLuup_reload" at the linux command prompt.

[akbooer]

Oh yes, that's the traditional Vera-compliant Luup API for you, which only allows string attributes.
TBH, I don't use that much these days. Sorry about that.

Two ways forward:

1. This will work right now:

local oL = luup.attr_get "openLuup"
oL.Tasmota = {
    Prefix = {"tele", "tasmota/tele", "stat"},
    Topic = {"SENSOR", "STATE", "RESULT", "LWT"}}

2. I could change the Tasmota code to accept:

attr ("openLuup.Tasmota.Prefix", "tele, tasmota/tele, stat")
attr ("openLuup.Tasmota.Topic",  "SENSOR, STATE, RESULT, LWT")

which might be better in the long run.

[Buxton]

@akbooer I'm good as I don't have additional topics that must be added at the moment. So the code change is probably the way to go.