Navigation

    Discussion Forum to share and further the development of home control and automation, independent of platforms.

    SmartHome Community

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Unsolved
    (Last Updated: February 11, 2021)
    • Openluup control of Alexa

      CatmanV2

      Very happy getting Alexa to control Openluup devices. I'm wondering if there's any way to get Openluup to control Alexa only devices (such as wifi enabled light bulbs?

      TIA

      C

      openLuup
    • openLuup: MQTT server

      akbooer

      Feedback / issues with openLuup's built-in MQTT server

      openLuup
    • openLuup won't upgrade from 2020.05.22

      R

      Hello,
      Having issues updating to latest version. Is there documentation on it anywhere?

      openLuup
    • Restoring OpenLuup

      A

      I thought I would test and migrate my OpenLuup installation from my current old i3 Ubuntu server to a new Raspberry Pi 4.

      I have set up the new Pi with a fresh install of openLuup and it works as it should.

      As I have understood it I should install all the plugins I have on my old installation and then restore a backup file from my old installation onto the new server. Is this correct or should I do some more steps before migrating? When I see that everything is working the plan is to swap the IP, but initially the new server will have another IP.

      When I tried to test the resore procedure on the new server from a backup file of the new server I got an error and the restore script hangs.
      After reboot OpenLuup is back.

      What I did was type:
      ./openLuup_reload backup/backup.openLuup-88800000-2021-04-12.lzap
      in the Terminal from inside cmh-ludl ( I found this procedure in an old thread).

      When doing this I get the following error message:
      rm: can not remove '/www/altui/altui*': The file of catalogue does not exist (free-hand translated from Swedish)

      @akbooer am I missing something here?

      openLuup
    • OpenLuup unavailable

      A

      The last three mornings OpenLuup for some reason has been unavailable. In other words it has not been responding when trying to connect via AltUI or Console.

      I have been trying to investigate a bit around what this could be but not got it pinned down.

      I run OpenLuup with one Zway bridge and two Vera bridges. The Zway and Veras have all been available every time, so that should not be the problem.
      When the problems started I had updated OpenLuup with Mqtt and added a few Mqtt devices. At the same time I also updated AltUI to the latest version. At the same time I also removed some devices from Room 101.
      The Mqtt devices are normally reporting data as they should.

      In Lua startup I have added the following entries related to Mqtt:

      luup.attr_set ("openLuup.MQTT.Port", 1883) luup.attr_set ("openLuup.MQTT.Username", "luup") luup.attr_set ("openLuup.MQTT.Password", "openluup") luup.attr_set ("openLuup.MQTT.PublishDeviceStatus", "0") -- ================================== Mqtt functions below: local json = require "openLuup.json" function MyMQTThandler (topic, message) local info = json.decode (message) local t = info.AM2301.Temperature local h = info.AM2301.Humidity luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 216) luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 228) end luup.register_handler ("MyMQTThandler", "mqtt:tele/tasmota_test/SENSOR") function TasmotaCO2Axel (topic, message) local info = json.decode (message) local t = info.BME280.Temperature local h = info.BME280.Humidity local p = info.BME280.Pressure local c = info.MHZ19B.CarbonDioxide luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 229) -- set temp to device luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 230) -- set humidity to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", p, 232) -- set air pressure to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", c, 231) -- set CO2 to device end luup.register_handler ("TasmotaCO2Axel", "mqtt:tele/TasmotaCO2Ax/SENSOR") function TasmotaCO2Anton (topic, message) local info = json.decode (message) local t = info.BME280.Temperature local h = info.BME280.Humidity local p = info.BME280.Pressure local c = info.MHZ19B.CarbonDioxide luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 233) -- set temp to device luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 234) -- set humidity to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", p, 235) -- set air pressure to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", c, 236) -- set CO2 to device end luup.register_handler ("TasmotaCO2Anton", "mqtt:tele/TasmotaCO2An/SENSOR") -- =======================================================================

      This morning it seems as if OpenLuup stopped working at 06:24, I kept MqttExporer up and running over night and it the data reporting had stopped at that time. (The image shows the last reported data and then it shows that it commences again after I restarted OpenLuup at 07:19.
      20210318MqttExplorer.png

      Before restarting I grabbed all the log files, the last few entries in the log are:

      2021-03-18 06:24:09.712 luup.variable_set:: 149.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: -10.6 now: -10.5 #hooks:0 2021-03-18 06:24:09.712 openLuup.server:: request completed (2 bytes, 1 chunks, 4 ms) tcp{client}: 0x55ca8d503438 2021-03-18 06:24:09.721 luup.variable_set:: 229.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 20.4 now: 20.4 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 230.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 46.7 now: 46.7 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 232.urn:micasaverde-com:serviceId:GenericSensor1.CurrentLevel was: 1016.5 now: 1016.5 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 231.urn:micasaverde-com:serviceId:GenericSensor1.CurrentLevel was: 2010 now: 2020 #hooks:0 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8cb5cf68 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c855e68 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8d2daa08 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c7c3218 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8ca87948 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8d312d98 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c7e95f8 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c74a218 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8bfefea8 2021-03-18 06:24:09.755 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c6ebce8 2021-03-18 06:24:09.756 openLuup.io.server:: MQTT:1883 connection closed tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: closed tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/TasmotaCO2Ax/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/tasmotas/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/TasmotaCO2Ax_fb/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: ERROR publishing application message for mqtt:cmnd/TasmotaCO2Ax/POWER : closed

      The last rows are a bit strange to me, them seem to indicate that something goes wrong with the Mqtt for that device?

      @akbooer I assume that it could be more of interest in the logs, I can of course email them if needed. Also let me know if any more information is missing.

      openLuup
    • My newbie questions

      Crille

      Creating my own topic for newbie questions about openLuup and AltUi 🙂

      Trying to create a scene with a timer to turn on device 1 at given time IF device 2 is Off.
      Wrote Lua to return false if device 2 is On.
      Log states "scene prevented from running by local scene Lua" but action is performed anyway, device 1 is turned On.
      Suggestions?

      openLuup
    • openLuup: Version Log

      akbooer

      A long while ago (May, 2015) I wrote my 2000-th post on another forum: openLuup - running unmodified plugins on any machine. Here’s the gist of it:

      ...I want to work in a more open and stable [Vera] environment...

      ...All would be solved if Luup was open source and could be run on the plethora of cheap and reliable hardware available today. But it’s not. But we could get something like that effect if we engineered a sufficient subset of Luup to run on such a platform. Could it be done? What would we need?

      1. UI
      2. scheduler
      3. web server
      4. Luup compatible API
      5. Device and Implementation xml file reader
      6. Zwave bridge to Vera
      7. runs most plugins without modification

      What we wouldn’t need is UPnP.

      What have we (nearly) got already?

      We have, courtesy of @amg0, the most excellent AltUI: Alternate UI to UI7, and that, I think, is probably the hardest one to do in the above list. Items 2 - 5, and 7, I’ve prototyped, in pure Lua, and posted elsewhere: DataYours on Raspberry Pi, running selected plugins unmodified, including: DataYours, EventWatcher, Netatmo, RBLuaTest, altUI. See screenshot attached.

      Is it worth the effort? Probably not. Will I pursue this quest? Yes.

      openLuup was the result.

      DE2056BF-E548-4611-972B-40276F00BFEB.jpeg

      openLuup
    • AltUI and Console gui

      A

      I found some really minor gui issues in AltUI and in the Console.

      Once more it is not that much of a problem for me as I use them only for admin purposes. I thought I'd post them anyway so that they are known for future releases, depending on priorities of course. 🙂

      The first is related to the rounding of humidity devices in AltUI. It seems as if these numbers are always rounded down:

      AltUI:
      cae85b7d-8f20-440a-9ca2-8d568b63f00c-bild.png

      Console:
      8100685e-9389-4f5f-b1e7-96a25fbabe84-bild.png

      The second issue is that the value for generic sensors seems not to be visible in the Console:

      AltUI:
      7909f921-2a09-4687-9550-331640e32244-bild.png

      Console:
      d090457b-5357-4bbd-9073-8f1e830c893f-bild.png

      Variables:
      6a9ec1a0-37e7-479e-94f0-4321f7aeac93-bild.png

      openLuup
    • New to openLuup, issues with scenes

      Crille

      I got tired on waiting for a stable release of Vera FW so finally took the leap to installing openLuup.

      Unfortunately I haven't even got a simple scene to work.
      Trigger - If device 1 is turned on
      Action - Delay 2 seconds and turn device 2 on.

      I see the call to turn device 1 on in log but nothing else related after that.
      What am I doing wrong?

      openLuup
    • Luup reload required after server reboot

      A

      I noticed this morning something that have seen in the past but forgotten about.

      When I restart the OpenLuup server (in my case an Ubuntu PC) the Vera and Z-way bridges do not get in contact with the corresponding servers, i.e. are shown in red in AltUI. The solution for me is to make a "Relaod Luup engine" and then they are ok. I do not know if it is a general issue or only for my setup.

      To be honest it is not much of a problem since OpenLuup is so stable. If and when you restart the server the hazzle of reloading is not that big. In fact I had forgotten about it since it was so long ago I had to restart anything...

      The one use case I can think of is that the server gets restarted due to a power outage or something and if you are not at home the system does not fully recover without manual interaction. I my case I have the server on an UPS, but still a thought.

      Is this a known issue and is it something that can be addressed somehow? As I said low priority, at least for me. 🙂

      openLuup
    • Wrong dimmer value in gui

      A

      I installed a new dimmer a few days ago, a Sunrichter "knob smart dimmer" (SR-ZV2835RACS).

      It included without problems into Z-way and shows up in AluUI and in the Console as usual.
      However the dimmer value in AltUI/Console does not change when you adjust it manually on the dimmer. I have checked the variables and it seems as if AltUI displays LoadLevelTarget and when checking on the dimmer variables the LoadLevelTarget value is not updated in OpenLuup when the dim level is changed on the dimmer. In other words LoadLevelStatus and LoadLevelTarget differs and LoadLevelStatus shows the correct dim level set manually on the dimmer.
      If you change the dim level in OpenLuup then both values are updated.
      On/off state is however always updated.

      In Z-way the dim level is updated as it should, so it works there as it should from what I can see.

      Running OpenLuup 20.12.19 and AltUI 2.53b.2552.

      @akbooer any idea if this is something that can be fixed?

      openLuup
    • Vera Decoupled from the cloud services

      therealdb

      so, @rigpapa did it: https://github.com/toggledbits/Vera-Decouple

      It's completely decoupling Vera from the cloud. Very cool stuff. /cc @rafale77 @akbooer

      openLuup
    • openLuup Icons

      rafale77

      This is a set of openLuup icons to replace the ones which you normally would transfer over from the vera. The only thing for the dimmable lights is that one needs to use a new json file to replace the original light bulb with an vector graphics type which I am also sharing.

      icons.zip
      D_DimmableLight1.json.zip

      This is a sample of the icons on ALTUI:

      Screen Shot 2021-03-01 at 16.06.18.png

      openLuup
    • Custom device for dimmer

      DesT

      @akbooer

      What's the effort/work to have a custom device "view" ?

      Remember when I talked about a dimmer with low/med/high/off instead of the slider from 0 to 100 ...

      What I would need to do to have that ?

      Right now, I have a fan in the living room that use the fireplace heat to send it on the 2nd floor!

      For the moment, I put it manually at 30%, 60% and 100% to handle the low/med/high, but will be more useful on the interface to have only 3 buttons...

      openLuup
    • Odd console display for triggers

      rafale77

      Screen Shot 2021-02-23 at 07.14.43.png

      @akbooer , I just noticed these last 3 watches which have a serviceID appended behind them in the console. It is only the last 3 and I can't figure out why. Any idea?

      openLuup
    • websocket

      rafale77

      A brainfart or maybe wishful thinking here but besides MQTT, it would be a really nice addition for openLuup to provide a websocket server which would "lock" the messages tighter than MQTT and then give allow MSR to connect to it through this protocol rather than the vera style http API.
      This came to me as I was observing MSR connection to openLuup through polling adding 0.3-0.4% of CPU load while not doing much of anything to Home-assistant. Just putting it out there. z-way-server also provides a websocket server through an app which could be used instead of the current fixed interval polling of the z-way bridge. MQTT would provide the same benefit but likely require a lot more user intervention to setup the MQTT topics and messages though it would lose the distributed clients/servers aspect.

      openLuup
    • Security Sensor LastTrip behavior

      rafale77

      I am not sure if this is the behavior inherited from the vera but I was looking at the codes and got annoyed that the LastTrip variable updates even when the variable set is to "untrip" the sensor. A bit of a pet peeve but I ended changing this behavior in the openLuup code to only update the LastTrip when it is a trip action. This is particularly annoying because of timed lighting or other sensors which are sending API calls to openLuup on a regular interval defeating the purpose (at least the one I think it is meant to have) of the variable.

      I just moved this line

      set ("LastTrip", tostring(os.time()))

      down to the armedtripped part of the code in the luup.lua file.

      @akbooer was there a reason for that behavior?

      openLuup
    • luaJIT

      rafale77

      @akbooer,

      Have you ever considered running openLuup under LuaJIT instead of Lua5.1 interpreter?

      The LuaJIT Project

      For kicks, I switched my installation to the latest LuaJIT2.1 beta3 dating from 2017 and being a lua5.1 interpreter it is a drop in replacement. I had to move the lfs library from one folder to another likely because of an include path difference but I am seeing a further speed/efficiency improvement vs. lua5.1.
      My CPU load has dropped another 25% to now hover around 2.2% down from 2.8%. I have yet to make sure that everything else works but so far everything appears to be the same.
      The luajit site claims up to 5x speed increase through the interpreter and 120x improvement through the compiler vs the standard lua5.1.

      Screen Shot 2020-07-05 at 23.10.02.png

      My initial interest was from being able to access some ffi libraries to handle video streams...

      PS: Wow it is pretty impressive under load... browsing through ALTUI which used to cause spikes of CPU utilization from 2.8% to 4.8% now only go from 2.3% to 2.6%. It almost looks like noise. I am running it on a pretty fast x64 thread so it may not be that significant but this could make a big difference on ARM.

      Screen Shot 2020-07-05 at 23.11.47.png

      openLuup
    • Missing App store contents in openLuup

      A

      A little while back the contents of the App Store in openLuup show that there are no plugins in the store and the date is shown as"

      Alt App Store (as of 1970-01-01 10:00:00)

      In the log I see this:

      2021-02-07 11:34:06.509 openLuup.wsapi.cgi:: /console : loading app database... 2021-02-07 11:34:06.550 openLuup.client:: WGET error status: -1, request: https://raw.githubusercontent.com/akbooer/AltAppStore/data/J_AltAppStore.json 2021-02-07 11:34:06.550 openLuup.wsapi.cgi:: /console : JSON decode error @[5 of 107, line: 1] unexpected data after valid JSON string 'tlsv <<<HERE>>> 1 alert protocol vers' 2021-02-07 11:34:06.569 openLuup.server:: request completed (8645 bytes, 0 chunks, 61 ms) tcp{client}: 0x34e2f68

      In AltUI, the store shows OK but I don't see a call to GitHub so it may be getting its info from a cached value or an xml file?

      openLuup
    • Generic support for external plug-ins in different languages

      therealdb

      I was toying with the idea to write a simple openLuup plug-in to execute any external plug-in (ie written in nodejs, puthon or even bash or .NET) via an openLuup plug-in, with access to luup's variables and/or the ability to execute actions against an external executable.

      The general idea is to get an existing library (ie: the one controlling LG TV, or SwitchBot) that's written in another language and write a simple (and generic) bridge to represent a device, getting variables from a command line bash script (or nodejs app or whatever) and leverage someone else's work, instead of playing catch-up and try to port it over to LUA.

      I did it by myself in my own fork of the MQTT2Luup bridge I released and it's working very well for me. I was able to implement support for Alexa, busylights, lgtv, netgear routers, switchbot and much more, all using established or official node packages, with a simple library to send command to the node lib (simulating a console in) and getting response from them (reading the console out). So my logic is still in the luup/openLuup engine and I could mix and match (ie: getting my TV volume to know if I want to raise up/down the thermostat temperature based on occupancy, or treat switchbots as normal light switch - and control them via Alexa and so on).

      So, instead of doing it all by myself, I'm wondering it this could interesting as a generic openLuup capability, or as a general and "standardized" effort. I know it sounds like MultiSystem Reactor, but it's not, since the primary purpose is to be specific to openLuup devices and leave the logic to the user (this could be of course Reactor, the upcoming MSReactor or whatever you want). Am I the only one mixing things together and with such a need?

      openLuup
    For those who registered but didn't received the confirmation email, please send an email to support@smarthome.community with the email you used

    Generic support for external plug-ins in different languages

    openLuup
    5
    21
    104
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • therealdb
      therealdb last edited by

      I was toying with the idea to write a simple openLuup plug-in to execute any external plug-in (ie written in nodejs, puthon or even bash or .NET) via an openLuup plug-in, with access to luup's variables and/or the ability to execute actions against an external executable.

      The general idea is to get an existing library (ie: the one controlling LG TV, or SwitchBot) that's written in another language and write a simple (and generic) bridge to represent a device, getting variables from a command line bash script (or nodejs app or whatever) and leverage someone else's work, instead of playing catch-up and try to port it over to LUA.

      I did it by myself in my own fork of the MQTT2Luup bridge I released and it's working very well for me. I was able to implement support for Alexa, busylights, lgtv, netgear routers, switchbot and much more, all using established or official node packages, with a simple library to send command to the node lib (simulating a console in) and getting response from them (reading the console out). So my logic is still in the luup/openLuup engine and I could mix and match (ie: getting my TV volume to know if I want to raise up/down the thermostat temperature based on occupancy, or treat switchbots as normal light switch - and control them via Alexa and so on).

      So, instead of doing it all by myself, I'm wondering it this could interesting as a generic openLuup capability, or as a general and "standardized" effort. I know it sounds like MultiSystem Reactor, but it's not, since the primary purpose is to be specific to openLuup devices and leave the logic to the user (this could be of course Reactor, the upcoming MSReactor or whatever you want). Am I the only one mixing things together and with such a need?

      1 Reply Last reply Reply Quote 1
      • PerH
        PerH last edited by

        No, you're not alone. 🙂 I have (at least) two plugins i want to "steal" from other systems, Tibber integration and Xiaomi Vacuum controller.. Found them in .NET, java and python..

        1 Reply Last reply Reply Quote 0
        • akbooer
          akbooer last edited by

          The real question is what the API should look like and what the parameter/command passing mechanism actual is. I'm happy to try and advise how best to integrate such a bridge with openLuup.

          1 Reply Last reply Reply Quote 0
          • therealdb
            therealdb last edited by

            I don’t have a solution. I want a formal way to do it, so we could write adapters and execute the code externally. Maybe something to easily map in/out console to variables/actions. I don’t want to do http requests and virtual devices, even if I’m doing this route and it’s somewhat ok, but not easily packaged nor user friendly (a lot of setup is needed). Using this route, instead, discoverability is possible.

            1 Reply Last reply Reply Quote 0
            • akbooer
              akbooer last edited by

              How about making them all MQTT clients?

              rafale77 1 Reply Last reply Reply Quote 0
              • rafale77
                rafale77 @akbooer last edited by

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

                How about making them all MQTT clients?

                I thought indeed that this was the very goal of MQTT... a universal and efficient framework to support multiple platform/languages. It just hasn't been super universal due to the diversity of implementations/lack of standards. It would be very interesting to see how all of this evolves into and I like the idea. I just don't know how to get there. MQTT is the closest I can think of.

                akbooer 1 Reply Last reply Reply Quote 0
                • therealdb
                  therealdb last edited by

                  Well, as you know I have MQTT in place for a lot of things, but you'll need a lot of manual steps. I think MQTT support inside openLuup is better than anything else, but I'm not sure auto-discovery could be easy. The fact that any device has its own commands could be easily resolved, as I did in my own bridge. It will require manual steps for sure, but it's doable.

                  1 Reply Last reply Reply Quote 0
                  • akbooer
                    akbooer @rafale77 last edited by

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

                    It just hasn't been super universal due to the diversity of implementations/lack of standards.

                    Really? I've been reading the OASIS standards document, and it seems very well defined.

                    MQTT Version 3.1.1

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

                    I think MQTT support inside openLuup is better than anything else

                    Are you talking as a philosophical point of view, or from a practical one? If the latter, then which client implementation (your own?)

                    I ask because I'm well into implementation of a QoS 0 MQTT server (aka broker.) It seems to me that this is the preferable approach when hosted by openLuup itself. It means that message travels directly between controller and device, rather than requiring two hops through a third-party (albeit local) server.

                    I already have my bare-bones implementation up and running for my Shelly devices. It's very fast and very easy to use from a plugin / Lua Test because you can subscribe directly to MQTT topics using

                    luup.request_handler ("MyMQTThandler", "mqtt:topc/name/goes/here")

                    The Shelly bridge requires no configuration, auto-installs when the first Shelly device announces its presence over MQTT, and fully configures child devices.

                    Hopefully available for wider testing in the not too distant future.

                    therealdb 1 Reply Last reply Reply Quote 0
                    • therealdb
                      therealdb @akbooer last edited by

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

                      Are you talking as a philosophical point of view, or from a practical one? If the latter, then which client implementation (your own?)
                      I ask because I'm well into implementation of a QoS 0 MQTT server (aka broker.) It seems to me that this is the preferable approach when hosted by openLuup itself. It means that message travels directly between controller and device, rather than requiring two hops through a third-party (albeit local) server.

                      nope, I was referring to yours 😄 Living inside openLuup is better from a performance point of view, no doubt here.

                      The Shelly bridge requires no configuration, auto-installs when the first Shelly device announces its presence over MQTT, and fully configures child devices.

                      sounds great, and this could be of use for future plug-ins as well. As I've already said, I have all kind of devices in place, using virtual devices and MQTT (temp, humidity, light sensors, distance, pressure, fertilization level, owntracks and many more).

                      Are you talking as a philosophical point of view

                      I think @rafale77 was referring to the lack of standardization of topics/messages. I think part of the work could be to just let this configurable for the users. As I said, I've now moved to MQTT and I'm currently dispatching events from my luup engine via my bridge/broker, and I'm using some of them to instruct my PC via a special Windows app. This way, I have notifications, but also events (ie: turn on lights via my PC if I'm at work when it's dark in the office, turn them off when the screensaver kiks in, show the cams automatically when there's motion, etc). All I did is to write a client and subscribe to my own topics. Very powerful.

                      rafale77 1 Reply Last reply Reply Quote 2
                      • rafale77
                        rafale77 @therealdb last edited by

                        @therealdb

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

                        I think @rafale77 was referring to the lack of standardization of topics/messages. I think part of the work could be to just let this configurable for the users. As I said, I've now moved to MQTT and I'm currently dispatching events from my luup engine via my bridge/broker, and I'm using some of them to instruct my PC via a special Windows app. This way, I have notifications, but also events (ie: turn on lights via my PC if I'm at work when it's dark in the office, turn them off when the screensaver kiks in, show the cams automatically when there's motion, etc). All I did is to write a client and subscribe to my own topics. Very powerful.

                        Indeed, that's exactly what I was referring to.
                        I was inspired by your comment on z-way supporting WebSockets and indeed... it does it through a plugin. It also supports MQTT. Would be a great idea to move the z-way bridge to MQTT? I was also looking at ALTUI and how heavy it is on openLuup when an ALTUI page is open as it polls the openLuup API at a high frequency. Wouldn't it be better if it connected through WebSockets or MQTT?

                        Screen Shot 2021-02-11 at 6.05.40 AM.png

                        Screen Shot 2021-02-11 at 6.06.06 AM.png

                        1 Reply Last reply Reply Quote 0
                        • therealdb
                          therealdb last edited by

                          with mqtt inside openLuup, you'll completely remove many, many HTTP calls, and you'll not need polling anymore. so yes, MQTT is better from this point of view.

                          akbooer 1 Reply Last reply Reply Quote 0
                          • akbooer
                            akbooer @therealdb last edited by

                            @therealdb
                            @rafale77

                            Indeed, it would make HTTP almost redundant for this application!

                            My development of openLuup’s own MQTT server is nearing the stage where it’s ready for Beta testing. It’s really nice to use with the Shelly devices (currently I only have i3 and sw2.5 implemented, but easily extended.). The bridge is by far the simplest that I have implemented, and so fast.

                            1 Reply Last reply Reply Quote 3
                            • rafale77
                              rafale77 last edited by

                              I am definitely looking forward to the embedded MQTT integration. I just revived my mosquitto broken and will be tinkering with it, time permitting.

                              1 Reply Last reply Reply Quote 0
                              • PerH
                                PerH last edited by

                                Just barely grasping the concept of MQTT here, but when you say embedded MQTT server, is that the same as a broker? or would one need that as a independent program?
                                If I understand this correctly, it seems to make many bridges redundant as well? Z-way, Domoticz, mabye not vera, but probably ezlo ..?

                                Sound interesting either way!

                                rafale77 1 Reply Last reply Reply Quote 0
                                • rafale77
                                  rafale77 @PerH last edited by rafale77

                                  @perh

                                  Let me try to explain it in more prosaic/layman terms:

                                  The way the z-way bridge, the vera bridge and domoticz bridge work today is the host controller (i.e openLuup) is polling the server at regular intervals to get updates on every device over http. This is the concept of the REST API polling. The host can also send singular commands to that API to control devices on the secondary controller. The polling scheme generates a lot wasted traffic obviously because there is traffic even when nothing is happening/changing.

                                  The idea is the same as for the zwave network management and the regular interval polling there which I advocated to eliminate back on the vera forum as z-wave devices don't need this anymore except for old light switches which did not support "instant status".

                                  Another way to do this is to trigger updates only upon events. That's much more complicated to do because it requires setup on both the host and secondary controllers. The secondary controller needs to know where to send the messages to when an event occurs. That's what I did for home assistant to openLuup using purely HTTP APIs. It is tedious and every new device requires manually creating a virtual device on openLuup and a set of scenes/automation on both controllers to update one another and keep their status in sync over HTTP calls but it is a lot more efficient.

                                  Now comes MQTT: It is a light weight protocol requiring a broker to manage all that traffic. It has all the various "clients" which are our controllers for example home assistant, z-way, openLuup etc... publish messages into topics. The broker then sends updates to all the controllers which subscribed to that topic. It is centralized event based communication and somewhat standardized as long as the different clients know how to interpret the messages and topics from one another (this is the part which is not standardized). It eliminates a ton of unnecessary polling and enables many clients to get updates instead of doing one to one communications.

                                  A server is not a broker. I think AK is working on a client/server for openLuup to subscribe and publish to MQTT. There has been a variety of plugin attempt to do this but doing it inside of openLuup is new and make a lot of things simpler.

                                  therealdb akbooer 2 Replies Last reply Reply Quote 1
                                  • PerH
                                    PerH last edited by

                                    Thanks!

                                    Have to correct you on the Domo bridge though, it includes a script in Domoticz that sends event updates immediately, polling is only needed if you havent installed that script. All that's needed in terms of domo setup is a user variable with an IP to openluup.

                                    I guess that the broker would be even another container in my setup then.

                                    1 Reply Last reply Reply Quote 0
                                    • therealdb
                                      therealdb @rafale77 last edited by

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

                                      It is centralized event based communication

                                      MQTT is distributed, to be completely right 🙂

                                      So you could publish messages to n brokers, subscribe to topics from m clients, and have k servers, all working together.

                                      Let put it in context.

                                      Shelly => Broker => openLuup
                                                       => Home Assistant
                                                       => MS Reactor
                                      

                                      or

                                      MS Reactor => Broker => openLuup
                                                           => InfluxDB
                                                           => your own client
                                      

                                      Possibilities are limitless. Bonus point is that you could integrate a lot of things (ZigBee2MQTT, ZWaveJS2MQTT, Hue2MQTT) with virtual no native plug-ins required in openLuup, beside a bunch of (easy) virtual device, to route the implementation of commands.

                                      I've asked the eZlo guys to do this for luup/ezlo fw because it's really powerfull, when you realize a single box is not enough in order to truly mix and match various techonologies.

                                      1 Reply Last reply Reply Quote 1
                                      • rafale77
                                        rafale77 last edited by rafale77

                                        @PerH
                                        Thanks for the precision on the domo bridge. I missed that.

                                        I am a bit allergic to containers... my entire setup (habridge/homekitbridge/z-way/home-assistant/mosquitto/openLuup/grafana) runs within a single VM on my NAS as I didn't see enough significant benefits of containerizing to justify the added complexity and overhead. It just takes 2 command line entries and a 2 line edit of a config file to install the broker. It is also much easier to upgrade and modify. Maybe I will come to it one day but I really nowhere close to it now.

                                        1 Reply Last reply Reply Quote 0
                                        • akbooer
                                          akbooer @rafale77 last edited by akbooer

                                          @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.)

                                          A 1 Reply Last reply Reply Quote 4
                                          • A
                                            a-lurker @akbooer last edited by

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

                                            I have, indeed, written a server, so you will not need Mosquitto, or any other server, installed anywhere

                                            Fantastic. Thanks for your efforts on this one ak. It should be a really good addition to openLuup.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post

                                            Welcome. If you’d like to participate in the discussion, rather than just read, then you can join the forum. As a member, you can interact with others here to share your experience and ask the questions you need answered.

                                            Powered by NodeBB | Contributors
                                            Hosted freely by PointPub Media Communications Inc. | Contact us