@akbooer said in Sun position or light sensor for blinds?:

Yes, it's all been done. You need @futzle's Heliotrope plugin.

Out of interest; I've modified/updated and re released Futzle's Heliotrope plugin in the AltApp store (with Futzle's permission).

Likewise; I've modified/updated and re released Chris Jackson's EDS one wire server plugin in the AltApp store (with Chris's permission).

The plugins listed here are available via the Alternative App Store. The app store becomes accessible via a new menu item in the Alternative User Interface once configured.

Both the Alternative User Interface (AltUI) and AltAppStore (AltAppStore) plugins need to be installed on Vera to access the store. With openLuup; this is all "automatically" set up and ready to go as part of the openLuup suite.

The Alternative App Store can be found here.

Publishing a plugin in the store is pretty easy. First your plugin code must be available in GitHub. Publish it, using the Publish command in the AltAppStore web page. You need to enter the salient information and it's ready to go.

Plugin icons can be stored on GitHub eg like so. After a "few days" the raw json describing the plugin appears here.

Vera 3 users should note the store will not work, as Vera 3 doesn't have the https capability required to access GitHub. However, the apps can always be downloaded from GitHub and manually installed.

For those just interested in what the store contains; refer to the list below - as of 2021 Mar 22 there were about 74 plugins available:

openweathermap looks good. You could probably get the DarkSky plugin to do both. They even have a mapping table already available:

OpenWeather to DarkSky mapping

Logs are are "good".

Just tell him/her, I'm going to subscribe to this site using his or her users name if he/her isn't quick

In 2017, bought a "Xiaomi Mi Robot Vacuum Cleaner Laser Distance Sensor NIDEC Brushless Motor, MPN: SDJQR01RR". Need to lift the smaller obstacles off the floor so it gets a good go at the floor and it can get stuck under some furniture. We have a mix of hard floor and carpet and it gets cleaned really well. Based on its work, it paid for itself very quickly. It maps the house with LIDAR and sends the map of my house back to China - no doubt there is some good data mining to be had in thousands of house plans!!! It vacuums in lines, up & down, rather than just bumping around randomly, like some of the older vacs do. Takes a while but that's only because it does a good job.

@akbooer said in Using luup.call_delay() in the browser code test boxes:

but have forgotten the details of how Vera behaved!

Just to remind you; badly.

OK not surprised I'm going around in circles - I should know better by now. I modified the example code to write to the log, instead of the UI. In Vera, in either Vera's UI or AltUI the log shows:

LuaInterface::CallFunction_Timer-5 function delayTest failed [string "local altui_device = 5..."]:10: bad argument #1 to 'insert' (table expected, got string)

Using AltUI with openLuup, I get similar, where 0x27151d0 is the called function (as printed by the test code):

luup.delay_callback:: function: 0x27151d0 ERROR: [string "RunLua"]:10: bad argument #1 to 'insert' (table expected, got string)

OK so then I test it in one of openLuup's three console test windows (I came across these just recently) and as expected with your code; it all works! I think I figured it had all failed because I never saw the test code printed in the log. Your console test windows just show this, rather than listing the code:

openLuup.server:: POST /data_request?id=XMLHttpRequest&action=submit_lua&codename=LuaTestCode2 HTTP/1.1 tcp{client}: 0x33b3328

So it can be made to work - looks like altUI and Vera UI need to pass the function reference, not the function name string? Or whatever is needed.

Out of interest I have noted that luup.call_delay can use sub one second delays in openLuup as previously mentioned on the Vera forum. I'm unsure if Vera can or can't.

I did some tests and found on a rasPi that occasionally, a one second delay could be well over one second on occasions (have seen two seconds). There could be any number of reasons for this - just measuring the time alone affects the timing (I used socket.gettime()). Plus with different things happening at the same time, it can get weird. But I do have a plugin that runs code every minute and receives/handles a lot of bytes, one by on, via the infamous Vera "'incoming" feature. I should probably rewrite that plugin code one day, if I can rember how it all worked.

There may even be an argument to code a finite reduction in all delays by some fudge factor representing the delay processing time eg say 20 milliseconds but that's getting too pedantic.

A plus for Telegram. Just a line like this will do it:

luup.inet.wget('https://api.telegram.org/bot'..botID..'/sendMessage?chat_id='..chatID..'&text='..urlEncode(msg),5)

AK - have to say I've been a bit lazy on keeping up with openLuup's graphing ability (and reading the manual). I see I can graph virtually anything listed here: Console--> Historian-->Cache. There is also DataYours but currently I'm doing this (can't even remember how this works):

http://openLuupIPaddress:3480/data_request?id=lr_render&target={cpu.d,memory.d}&title=CPU (%) Memory (Mb)&height=750&from=-y

Unsure what's ancient technology or what each one entails eg AFAIK Grafana needs a Grafana server to be set up, etc. Presume that can be done on a RasPi.

What URL shows what you have shown above.(may be we need a new thread for openLuup graphing techniques?)

A few points:

• My last mods to the Lua file would have no useful effect, so my bad. It's been a while since I looked at this code so my memory is a bit out of date.
• No "RF child" is produced. You get one child per physical Broadlink device (if they are known to the plugin). That child handles both RF & IR, as the sent code is either an IR or RF code.
• I see three IP addresses in the logs provided, which makes understanding the log a little tricky. Regardless the plugin knows the physical devices by their MAC address, so the IP address can change around. Have you fixed IP addresses for the BroadLink devices?
• I probably need to make the logging a bit clearer on what's going on.

On the aircon - the BroadLink protocol is not published and they change it from time to time so reverse engineering is always on going.

On the RM4 Pro - this tells me its been discovered OK:

{"a0:43:b0:18:de:8d":{"blInternalId":"00000001","blKey":"a7c5df0a9133f188c982a56dc8bcf9df","blDeviceType":25755,"blIp":"10.1.11.20","blDesc":"RM4 Pro"}}

I assume here that the MAC listed above is the MAC address of the RM4 Pro? There is no list of found devices in the plugin's GUI representation (there probably should but I didn't do one). The json above is the "list" and it looks fine. Once a device is defined in the json it stays there; even if the device goes off line (for whatever reason) and therefore not discoverable. If the IP address changes the json is updated to match.

The final problem is the "cloud bit". Some of the newer devices get this bit set when the app is used with the device and it causes issues. I have no experience of any of this, as I my devices don't have it. Need to read the thread at the other site, that talks about the reset/pairing procedure to avoid problems.

Also is this is on a Vera or openLuup?

Try relocating the Broadlink device closer to the WiFi connection. I still maintain the comms may be a bit flaky. If you send any IR code to the device the log will show what's happening and you can use a cellphone camera to see if the IR is coming out of the RM4 Pro.

I have no plans to get this to work for the aircons - looks like a major effort; especially if you have no hardware to test the code on.

Second: EDIT: yes the Broadlink device was not producing an RF child. It should be fixed: see latest lua file in GitHub ver 0.57a. There are so many variations of all these devices it's hard to keep up.

On this:

2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: This device is probably offline - mac address: a0:43:b0:18:de:8d

The Broadlink device may be on the edge of its WiFi range.

Note that the plugin now also allows you to send codes in base64 format. Just send them and the plugin will work out if they are base64 encoded.

For reasons unclear Home Assistant seems to use them. However they have thousands available for Aircons

First on this:

2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: The BroadLink device at IP address 10.1.11.126 and of type 0x4e2a is not known to this plugin

and

Friendly name: e5a5a5e5858be696afe7a9bae8b083

Getting the last bit and reformatting it a little:

\xe5\xa5\xa5\xe5\x85\x8b\xe6\x96\xaf\xe7\xa9\xba\xe8\xb0\x83

and sticking it into this UTF8 enc/dec you get the attached image. If someone knows what it means, I would be interested in knowing - I suspect it something to do with aircons.

It seems that a few air conditioners are now using the Broadlink protocol. They are controlled with a mobile app called AC freedom and they use the Broadlink devtype 0x4E2a (20010dec).

So in short the plugin doesn't handle A/Cs. @ronluna can you tell us more about this Broadlink / Aircon device?

More info here: on the A/Cs

In 2017, bought a "Xiaomi Mi Robot Vacuum Cleaner Laser Distance Sensor NIDEC Brushless Motor, MPN: SDJQR01RR". Need to lift the smaller obstacles off the floor so it gets a good go at the floor and it can get stuck under some furniture. We have a mix of hard floor and carpet and it gets cleaned really well. Based on its work, it paid for itself very quickly. It maps the house with LIDAR and sends the map of my house back to China - no doubt there is some good data mining to be had in thousands of house plans!!! It vacuums in lines, up & down, rather than just bumping around randomly, like some of the older vacs do. Takes a while but that's only because it does a good job.

This also works but it does not return json: my ip address. There are a few others including this. EDIT: looking at this further; there are lots of site that will do this.

Hi ronluna

Great to see more stuff supporting openLuup and the like. If you feel like adding the plugin to the Alt App Store; I can add it to the list of available plugins:

https://smarthome.community/topic/247/list-of-plugins-available-at-the-alternative-app-store?_=1615766458771

Mmm looked high and low for the Shelly bridge and can find no mention of it. Using openLuup ver 2021.03.01b. What's the trick?

If you feel like linking it to the store I'll update the store list: List of plugins available at the Alternative App Store.

We should round up as many old plugins that we find and get them into GitHub and the store (as long as they are not proprietary). eg I would like to see the Sonos app in the store (it's in GitHub) but togglebits seems to be busy on some other new fangled plugin.

WARNING: DO THIS WRONG AND IT ALL GOES BADLY WRONG.

Following refers to openLuup running on Jessie, on a RasPi with openSSL version:

OpenSSL 1.0.1t 3 May 2016

I made the mistake of running this command in the hope of it fixing the Telegram and the GitHub app store access problems I was having:

sudo luarocks install luasec

No good - can't find what's needed. So do this:

sudo luarocks install luasec OPENSSL_LIBDIR=/usr/lib/arm-linux-gnueabihf/

All goes OK - reboot the RasPi. And then errors:

/etc/cmh-ludl$ /etc/cmh-ludl/openLuup_reload
lua5.1: error loading module 'ssl.core' from file '/usr/local/lib/lua/5.1/ssl.so':
	/usr/local/lib/lua/5.1/ssl.so: undefined symbol: X509_get_signature_nid
stack traceback:
	[C]: ?
	[C]: in function 'G_require'
	openLuup/init.lua:86: in function 'require'
	/usr/local/share/lua/5.1/ssl.lua:8: in main chunk
	[C]: in function 'G_require'
	openLuup/init.lua:86: in function 'require'
	/usr/local/share/lua/5.1/ssl/https.lua:10: in main chunk
	[C]: in function 'G_require'
	openLuup/init.lua:86: in function 'require'
	./openLuup/client.lua:39: in main chunk
	[C]: in function 'G_require'
	openLuup/init.lua:86: in function 'require'
	./openLuup/luup.lua:85: in main chunk
	[C]: in function 'G_require'
	openLuup/init.lua:86: in function 'require'
	openLuup/init.lua:93: in main chunk

Many hours later after much bashing of keyboard - removed luasec:

luarocks remove luasec

And install the most recent version of luasec version 0.7 that will work with the old openSSL version "OpenSSL 1.0.1t 3 May 2016":

sudo luarocks install luasec 0.7 OPENSSL_LIBDIR=/usr/lib/arm-linux-gnueabihf/

Note this this link where it says:

Notice:

• LuaSec 0.8 requires at least OpenSSL 1.0.2.
• For old versions of OpenSSL, use LuaSec 0.7.

Telegram and App Store access now fixed but I did so much messing around in between, it's hard to say if this is the actual fix!

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