Well, this probably won't be the last time that someone from there joins us here, but, for the time being, I think it's time to move on.

We have a critical mass of really constructive contributors here, and we should certainly be doing what @toggledbits suggests:

• "a place where technical discussion can lead over corporate policy "
• "take a wide view of the HA market, and not be beholden to one product"
• "We get work done. We get work done for each other."

"Make it so!"

Clearly deranged. All I ever wanted to do was support openLuup users, and point out that, under the new regime, that was best done here rather than there!

@pabla said in Vera account suspended for a 1000 years:

you just don't know what you could say that will get you banned.

...I just mentioned bicycle wheels!

Anyway, welcome. Glad you're here.

I now have an alpha version of openLuup using MQTT to send ALL device variable status updates in real time. This beats the heck out of almost any other approach in terms of latency.

It publishes to topics named openLuup/device_no/short_service_id/var_name (where short_service_name is the useful part of the serviceId – ie. the last alphanumeric bit.) Here's a screen shot of MQTT Explorer watching this test system which is linked to a Vera.

Under openLuup, you can use the native App Store page...

http://openLuupIP:3480/openLuup?page=app_store

...which, of course, shows only openLuup compatible plugins. It's also very responsive.

Hovering over the plugin icon shows the description, and there are links to the App Store JSON and GitHub repository if you're a developer wanting to browse those.

Liking @LibraSun ’s statistical analysis of the situation there!

Also amused at the publication of my PM, which, in fact, was obviously personalised, and you can easily work out who it was sent to because of the specific mention of HomeWave. I may have sent other similar ones, but they would most probably have been directed specifically at openLuup users.

@perh said in Generic support for external plug-ins in different languages:

MQTT server, is that the same as a broker?

@rafale77 said in Generic support for external plug-ins in different languages:

A server is not a broker.

To be sure 'server' is an overloaded term. However, within the scope of MQTT, a server is a broker. The OASIS MQTT specification (version 3.1.1, which is what I'm implementing) uses the term exclusively, and defines it (on lines 31-32) thus:

"A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions."

I have, indeed, written a server, so you will not need Mosquitto, or any other server, installed anywhere, although, as @therealdb points out, you can have multiple servers (on different ports.)

Development Branch: 2021 Release 5.23

Significant changes and additions to the Data Historian:

• Variable graphing pages enables plotting of any of the archives or the in-memory cache
• Database editor to view variable values and commit changes to the database
• Support for multiple Graphite Carbon databases (complete replacement for DataYours)
• New console page to show rules for which variables are cached and/or archived
• Historian archive rules now independent (decoupled from old Whisper database .conf files)

In addition, the openLuup plugin device now has variables for solar Right Ascension (RA), Declination (DEC), Altitude (ALT), and Azimuth (AZ), which are updated every two minutes. Also a GetSolarCoords action which gives these values for any given time (defaults to now) and latitude/longitude (defaults to current location.) These calculations have always been done by openLuup to support scene times of sunrise/sunset, but are now available for use (negating the need for a separate plugin, eg. Heliotrope.)

Master Branch: 2021 Release 7.25

Long-overdue roll-up of the last year's development updates!

including...

• MQTT QoS 0 server
• UDP -> MQTT bridge
• Shelly device support
• Tasmota device support
• Highlighting of errors on log pages
• Simplified Shelly-like HTTP commands for device control
• Automatic substitution of JSON module with RapidJson, if available
• Data Historian improvements including better archive data plotting
• Solar coordinates available (for shades / lighting / etc...)

As ever, enormous thanks to those who provide ideas and feedback, or even criticism!

AK

@rafale77 said in Deconz:

Not giving up on the idea of a bridge for openLuup

Currently I’m working on new concepts for plugin implementations, taking Shelly as an exemplar. If successful, this could be a framework for other protocols.

Unlike the other place, I’m looking for a seamless evolution of API and capability. The BIG IDEA is to implement ‘plugins’ as CGI files which could be run under almost any web server. A significant part of openLuup’s extended functionality is already implemented in this way (Historian, Console, ...) For a complete transition, I would need to wrap some existing parts (Luup requests, bridges, ...) as CGIs. This would, eventually allow me to lose the weakest part of openLuup, which is its own web server...

@toggledbits said in openLuup: SmartSwitch plugin:

I can't believe I never did it... but it's done now!

Is it just me? ... I can't see it in the Alt App Store.

@DesT

OK, let's try that again...

...a small fix to change SwitchNames to SensorNames !!

The above file has been updated.

My test now looks like this:

Ah, OK, my misunderstading. It's not a device I've used myself, and I didn't test it with more than one SmartSwitch.

..but at least it shows this should be possible in Lua, without any additional JavaScript.

@dest said in openLuup: SmartSwitch plugin:

I never use multiple devices

OK, you'll find an updated Lua file, v2.0.3, here:

It lists the name of the first trigger device. In the event that you do use more than one trigger, there will be an ellipsis "..." added after the first name (to give at least some visual indication that something is going on.)

I've done nothing to guard against the line overflowing or wrapping because of a long name.

@DesT

I've installed SmartSwitch on my development machine, and I think I'm not understanding something...

...it's the case that there could be multiple trigger devices, hence you'd need room for multiple names here?

The Settings tab is all JavaScript stuff, not Lua. Although the device panel data is stored in a device variable (and set in Lua) I'm not sure where to find the relevant information. I'll have to look more closely.

Glad to hear it!

I just looked at the code again, and indeed there's a NameDevices variable, which currently does absolutely nothing. I know that I looked at this several times and threw my hands up in disbelief at how hard it was going to be... but I can't remember why!

Have you tried just deleting the devices in question and reloading?

(easy to delete a bunch of devices quickly from the console Devices Table page.)

What problem are you trying to fix by doing this?

Thanks so much. I have to say that a lot of the innovation comes from others (like yourself!)

Following your message, I've updated the version log to list some of the improvements over the last year.

I do have some things in progress, including:

• better support for scenes – although I rather suspect that nobody will use scenes since the advent of Reactor / MSR
• AltAppStore updates (for openLuup only) through GitHub pull-requests
• possible real-time updates for console device and scene pages
• finish missing parts of console interface
• use of standard HTTP servers through CGI interface (perhaps, one day)

@a-lurker said in Long-overdue roll-up of the last year's development!!!:

an "App Store" plugin download count

...Ah yes, well that will be tricky, and of course we've missed more than a few downloads already!