openLuup email server

[Elcid]

No I don't run any pc's. I can connect the shellies to mosquitto on a sperate machine with no issues.

[akbooer]

I run Explorer on a Mac, but OK, I’ve no idea what’s (not) going on, then.

[Elcid]

OK after a couple more reloads, I have success in getting shelly bridge to load in altui. All I changed was the the name to a custom name. tried giving an extra path e.g. "shellix3/name". That half worked and openluup installed the bridge, but half the variables were missing. I then tried shellyix3-name and all fired up.
Cheers for replies.

[therealdb]

@perh said in openLuup: MQTT server:

A button for "Create Device" with entrys for "Device type", "topic", ... <-whatever you need to assign the recieved/sent value to a sensor/button.

Would you be more interested into the UI part (I've never really coded anything in particular, but it's probably time to start...) or the raw features (ie: changing some very simple parameters?).

The latter is pretty easy and I'll probably have a working build for sensors and switches/dimmers pretty soon.

[therealdb]

Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done

You can mix and match different kind of commands (lua, mqtt, http, curl, etc).

I'll try to do some refactoring in order to use a common lib for all this virtual devices, then backport this to all of them, then start adding watches, so we could subscribe to mqtt messages and update variables. @PerH @akbooer

[PerH]

@therealdb
I'm just thinking that the UI would enable people not familiar with MQTT or its nomenclature to use it.. Not having to go to lua code would definately be a step in the right direction. Mabye with some "proof reading" on the input too? as pop-ups if theres illegal characters and so on.

[therealdb]

@perh I could definitely develop a configuration page. It's on my TODO list since the first alpha was out. I'll try to write the code to support this feature first, then try to implement a configuration page and finally close the gap, since these devices have a lot of capabilities, but you'll need to configure them manually - and that's the same problem with yaml and Home Assistant, for example.

[akbooer]

@therealdb said in openLuup: MQTT server:

Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done

That's great. Glad we asked! ... saved me a lot of work

[Buxton]

Hey AK, per the above about configuration options, it seems to me that a console page displaying every single topic that arrives at openLuup is the way to start the configuration process. Perhaps with a clickable sort option based on topic or prefix. I'm thinking of a checkbox to the left of a list of topics that allows one to subscribe, with the most current message displayed just underneath the topic syntax. So a two line notation for every topic. Then a second checkbox called purge for old obsolete topics that are no longer used (which would vanish on a luup reload).

A subscription table should eliminate hard coded prefixes in the Tasmota bridge as the bridge would create generic MQTT "devices" based on what topic name you subscribe to. From there, you can create sensors, switches etc based on what you want to pull from the MQTT device.

[Buxton]

This post is deleted!

[Buxton]

@akbooer

I downloaded the latest development version 21.4.25 and am now seeing the following behavior where the AltUi tags/category etc disappear from the device page:

Here is the same screen shot using the master branch 20.5.22. This was captured only minutes later when I downgraded to the master branch:

As well, I'm seeing receive errors again in the log for the MQTT connection to mosquitto. These errors were not present in 21.4.18 but an update to 21.4.25 shows them back with my Mosquitto connection flopping with each error..... is there any way I can revert to 21.4.18. I tried a couple of different syntax changes in the plugin update field, but I can't pull any development version except for the current one.

[Buxton]

@akbooer As best as I can tell, the mqtt.incoming function is being sent nil values, so you go straight to the error handler because "client" is nil and therefore "message" is nil. Debug code below:

  local message, errmsg = MQTT_packet.receive (client)
  
  local sClient, sMessage, sCredentials, sSubscriptions = unpack(client), unpack(message), unpack(credentials), unpack(subscriptions)
  
  if sClient == nil then sClient = "nil" end
  if sMessage == nil then sMessage = "nil" end
  if sCredentials == nil then sCredentials = "nil" end
  if sSubscriptions == nil then sSubscriptions = "nil" end
  
    _log ( "client " .. sClient .. " message " .. sMessage .. " creds " .. sCredentials .. " subs ".. sSubscriptions)

Creates the following sample log message:

2021-04-25 18:51:22.332   luup.tasmota:262: Topic ignored : tele/power_BedroomTV/INFO2 : {"WebServerMode":"Admin","Hostname":"power_BedroomTV-4552","IPAddress":"10.17.2.28"}
2021-04-25 18:51:22.333   openLuup.mqtt:: client nil message nil creds nil subs nil

2021-04-25 19:00:44.833   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55fd83233948

[ArcherS]

@buxton I can confirm the same problem. Om my test Pi running v21.4.25 (and AltUi 2.53c) the AltUi tags are missing and on my main server still running v21.4.18 the tags are there.

I do not however have any new Mqtt errors on the v21.4.25 server, but then I am not connecting to mosquitto either.

[akbooer]

OK, apologies to all. I obviously need to improve my pre-release testing in this area. I don’t use AltUI much these days, and it’s hard to automate tests. I’m not seeing any MQTT errors, either.

I will tag the earlier release so that you can revert. Will let you know when that’s done.

Sorry, again.

[akbooer]

@Buxton @ArcherS

OK. tagged release v21.4.18 should now be available.

[akbooer]

FWIW, I've now updated, and hopefully corrected, the code – v21.4.26 is the latest development version. So, I'd be very grateful if anyone is brave enough to test this.

I'm really glad of this error being highlighted, beause it's caused me to re-think somewhat the openLuup object API, and I'm rather happier with the outcome now. No guarantees, of course, that this fixes all the problems, but I hope that it is a step in the right direction.

PS: One of my systems exhibited the AltUI missing buttons, but, curiously, one did not. However, they both appear to work OK after this update.

[rafale77]

@akbooer

Did you revert the chdev.lua file all the way to dec 2020 version? It seems to be a mistake but I wanted to check nevertheless...

[akbooer]

Yes, that's correct. It effectively rips out some recent changes which now don't fit with the roadmap forward.

I had previously been adding, partially hidden, features to the usual luup API. My plan now is to freeze the functionality of that API (which is what third-party plugins use, including AltUI) but to extend the underlying openLuup object-oriented API. In doing so, I hope to minimize the chance of breaking working plugins.

In this particular case, the changes have been to 'virtualize' device variables so that they can now be addressed directly as program variables, rather than having to resort to get/set functions. The Shelly and Tasmota bridges use this approach.

[Buxton]

@akbooer With .26, the sub-menu is back, and I don't see any errors outside of the MQTT receive error.

I wouldn't be overly concerned with "Development" branches breaking things. That's the risk users take with deploying those branches. I'm stoked on your MQTT advances and am more than willing to troubleshoot the inevitable bugs that pop up when building out new features....

[ArcherS]

@akbooer installed v21.4.26 on my test Pi and it seems to work.
The AltUi tags are back. The Shellies seem to work, also the Tasmota seem to update.
No errors in the log so far.