Just on AltUI:

The browser would be downloading any number of resources first time round from various servers. But I would have thought the majority of servers would be using some sort of cache control header combinations to the command the browser's caching. You don't need to be downloading jquery every time you hit a web page and I think it's unlikely that would be happening.

So I would have thought that the browser (for AltUI) could have cached most of what AltUI needed? What resource is the browser calling up that it can't download with the internet connection down? Maybe AltUI could have functioned but in some sort of reduced capability mode?

But yes the openLuup console, as I understand it, has been written to not rely overly on outside resources. Surprising akbooer could get it work!!

I had this problem a long time ago:

You need to set up the required files locally somewhere. On a local directory, NAS, USB stick, web server etc. You then have the responsibility of keeping them up to date. Some things may still not work like Goggle charts.

amg0 set up a variable in the AltUI plugin labelled "Local CDN ?" that can be used to point to the new local file source. So it's not hard to switch back and forth.

In normal operation (ie using the internet) this variable is blank. You can read amg0's doco from here at GitHub

The old forum discussion here.

"AK: Your best bet would surely be to register a callback handler to listen for messages on a specific address?"

Yep - that seems the most obvious method - just wanted to make sure I hadn't missed some other turn of events. With your own callback handler, you can clearly sort out any email encodings, etc.

On the Doco - Goggle doesn't seem to index github io pages. Seems to me you need to have some sort of URL redirect, that looks like say https://smarthome.community/openluup, that would get indexed? ie via the web server set up or similar.

Hello AK

Have been writing about the openLuup email server as I was tinkering with it the other day. One minor problem: it looks like the domain part of the email address eg ...@openLuup.local is case sensitive in openLuup.

Looking round the net, it suggests that the local part is case sensitive but the domain part is not meant to be. To keep things so they are more likely to work, it's suggested the email address should be totally case insensitive regardless. Refer to rfc2821 page 13 or search on the word "sensitive". Suffice to say I was using mail@openluup.local rather than mail@openLuup.local, so it didn't work for me.

Next challenge was that the file saved in /etc/cmh-ludl/mail has "Content-Transfer-Encoding: base64" so the body of the email was encoded:

Received: from ((openLuup.smtp) [ip_address_1]
 by (openLuup.smtp v18.4.12) [ip_address_2];
 Tue, 26 Nov 2024 14:21:22 +1000
From: "dali@switchboard" <dali@switchboard>
To: "mail@openLuup.local" <mail@openLuup.local>
Subject: Warning form R2E.
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: base64

QXV0byBXYXJuaW5nOiBDb2xkIHN0YXJ0IGV2ZW50

The above base 64 text translates to "Auto Warning: Cold start event".

Is it your preference to leave the saved files in the raw mode or would you consider translating the base64 text in the openLuup code base?

On a side note, does the reception of an email by openLuup generate some sort of trigger that can be watched. In the case above; the email represents the restoration of power after a power outage. I would like to know about that by the email triggering a "Telegram" notification on my mobile.

I see that the images@openLuup.local images@openLuup.local can be associated with I_openLuupCamera1.xml, which spawns a movement detector child. Anything similar for the other email addresses?

Now fixed in the Development branch.

The code in your link was messed up when they updated that forum some years ago. I've rehashed it to give it a chance of working but I suspect you may still have trouble getting it to work. Running it in the Lua test window would be your starting point after reading the
push over api doco.

Another alternative is to use Telegram with the Telegram plugin.

-- Refer to pushover documentation:
--   https://pushover.net/api

local pushToken    = "YourPushOverTokenHere"
local pushUser     = "YourPushOverUserCodeHere"
local pushTitle    = "MessageTitle"
local pushMessage  = "MessageContent"
local snapshotFile = "/tmp/camera_snapshot.jpg"
local pushPriority = "1"

-- Sound could be: pushover bike bugle, cash register, classical, cosmic, falling,
-- gamelan, intermission, magic, mechanical, pianobar, siren, spacealarm, tugboat,
-- alien, climb, persistent, echo, updown, none
local pushSound = "gamelan"

-- Link to the BlueIris videostream of that camera
local pushUrl = "http://xxx.xxx.xxx.xxx/mjpg/ShortCamName&user=XXX&pw=XXX"
local pushUrlTitle = "Camera Name"

-- This points to one of my BlueIris managed cameras
local camera = "http://xxx.xxx.xxx.xxx/image/ShortCamName?q=50&s=80&user=XXX&pw=XXX"

-- Get the snapshot from the camera
local out = assert(io.open(snapshotFile, "wb"))
local _,data = luup.inet.wget(camera)
out:write(data)
assert(out:close())

--Send PushOver request
local curlCommandTab = {}

table.insert (curlCommandTab, 'curl -s')
table.insert (curlCommandTab, '-F "token='      ..pushToken    ..'"')
table.insert (curlCommandTab, '-F "user='       ..pushUser     ..'"')
table.insert (curlCommandTab, '-F "title='      ..pushTitle    ..'"')
table.insert (curlCommandTab, '-F "message='    ..pushMessage  ..'"')
table.insert (curlCommandTab, '-F attachment=@' ..snapshotFile ..'"')
table.insert (curlCommandTab, '-F "sound='      ..pushSound    ..'"')
table.insert (curlCommandTab, '-F "priority='   ..pushPriority ..'"')
table.insert (curlCommandTab, '-F "url='        ..pushUrl      ..'"')
table.insert (curlCommandTab, '-F "url_title='  ..pushUrlTitle ..'"')

-- The .json suffix requests that the response be in JSON format
table.insert (curlCommandTab, 'https://api.pushover.net/1/messages.json')

local curlCommand = table.concat (curlCommandTab, ' ')
print(curlCommand)

local handle = io.popen(curlCommand)
local result = handle:read("*a")
handle:close()
print (result)

-- Delete temporary snapshot
os.remove (snapshotFile)

May be better to get a DIN rail high powered contactor and use a Shelly to flip that on & off.

AK. Was doing an openLuup install and the installer errored with:

openLuup_install   2019.02.15   @akbooer
getting openLuup version tar file from GitHub branch master...
un-zipping download files...
getting dkjson.lua...
lua5.1: openLuup_install.lua:45: GitHub download failed with code 500
stack traceback:
        [C]: in function 'assert'
        openLuup_install.lua:45: in main chunk
        [C]: ?

The installer code was executing this URL:

http://dkolf.de/src/dkjson-lua.fsl/raw/dkjson.lua?name=16cbc26080996d9da827df42cb0844a25518eeb3

Running it manually gives:

dkolf.de

The script could not be run error-free.
Please check your error log file for the exact error message. You can find this in the KIS under "Product Management > *YOUR PRODUCT* > *CONFYGUAR* > Logfiles". Further information can be found in our FAQ.
The script could not be executed correctly.
Please refer to your error log for details about this error. You find it in your KIS under item "Product Admin > *YOUR PRODUCT* > *CONFIGURE* > Logfiles". Further information can also be found in our FAQ.

I'm thinking the dkjson code URL has been changed. On dkolf.de there is a download link:

http://dkolf.de/dkjson-lua/dkjson-2.8.lua

and dkjson code also seems to be in GitHub (I presume this is the same code?):

https://github.com/LuaDist/dkjson/blob/master/dkjson.lua

I'm don't know what dkolf.de looked like previously but I do see the dkjson code has been updated as of 2024-06-17. Hope this helps.

Oh - and by the way the dkjson.lua file seems to have been downloaded OK by the installer - error or no error, so go figure.

Tried out the above start up code and it has done the job. Now have lots of Shelly based files that can now be plotted using Grafana. They all have the same retentions but so far that's not a problem.

Great - thanks very much.

Easily answered: Whisper Database Format

OK

You should absolutely not create any extra files in the Historian folder.

OK - assume it's all meant to be private to openLuup. Best not to mess with its own little world.

IIRC, the Historian substitutes / in the file names it creates.

However whisper.create (filename,archives,0) does not. The string

"whisper/0.10006.shellypro3em.em1/0/act_power.wsp"

is used as is.

Ultimately I would like to have openLuup save the data for any variable I nominate and it gets saved no matter what the variable is called. I imagime forward slashes could be replaced with say dashes (underscores are already in use by Shelly).

The openLuup instance where I have the em1/0/act_power.wsp variable does not have DataYours installed. You have said however that any files in a whisper directory will get updated. Is that right? I though the whisper directory had be specified in DataYours?

So a little confused on how "em1/0/act_power.wsp" or any other variable with slashes can be charted. I can see how having children set up for each device could be set to do this but ultimately you need to be able to plot any variable of ones choosing.

For example the Shelly Pro 4pm also measures power (very useful) but the variable is "switch/0/apower" ie a completely different layout.

Variables don't have to be picked off a list - they could just be manually set up by ruuning a snippet of code such as "whisper.create" as seen above.

Currently I have some Whisper files used by DataYours that been working well for ages and do what I want.

One of the files is called Watts_L1.d.wsp and uses this retention from "storage_schemas_conf" in openLuup file virtualfilesystem.lua:

[day]
pattern = \.d$
retentions = 1m:1d

Inside the actual "Watts_L1.d.wsp" file is a header like so:

         1,      86400,          0,          1
         84,         60,       1440

The 1, 86400 is one minute & one day (in minutes) as per the retention listed above. As a side issue I would like to know what the other header values mean ie what's the syntax here?

New challenge: I now have three Shelly variables named:

em1/0/act_power
em1/1/act_power
em1/2/act_power

with a device ID of "10006" and a SID of "shellypro3em"

And I would like to plot them using the Historian, just like I do with Watts_L1.d.wsp in DataYours. So I need a file in the history directory for the data. So I looked at doing this:

local whisper = require "openLuup.whisper"

-- Syntax:  history/0.deviceNumber.shortServiceId.variableName
local filename = "history/0.10006.shellypro3em.em1/0/act_power.wsp"

local archives = "1m:1d"

whisper.create (filename,archives,0)

Problem is that the variable names contains forward slashes, which are invalid filename characters. What to do?

Also should the retentions now be (to suit the latest openLuup software)?:

local archives = "1m:1d,10m:7d,1h:30d,3h:1y,1d:10y"

Also "shellypro3em" is not a "shortServiceID" as per those listed in "servertables.lua". So can "shellypro3em" be used instead? ie can both short and long service IDs be used in the above call to whisper.create?

Try getting the json and checking it here. Also may be a decoding problem for the currency symbol. Try changing the currency to one simple character. The a-circumflex symbol before the pound symbol looks odd. UTF-8 versus ISO-8859-1 ?

The code above before it is reformatted has ", at the very end:

Any other startup processing may be inserted here...\nluup.log "startup code completed"\n\n",

OpenWeatherMap's API changes: Some time back OpenWeatherMap decided to change their API billing practices. The old "One Call API" arrangements (1,000 API calls per day free) have now ended.

You now have to provide your credit card details, so if you exceed the free 1,000 API calls per day you can be charged. The provided API keys don't work unless you provide these details. Returned error message:

{
  "cod": 401,
  "message": "Invalid API key. Please see https://openweathermap.org/faq#error401 for more info."
}

However, if you just want current weather with no forecasts, you can use the "weather" call:

https://api.openweathermap.org/data/2.5/weather?lat=%s&lon=%s&units=%s&lang=%s&appid=%s

It's possible the Multi Station Weather plugin could be modified to fall back to this call, if it fails on the first call. As suggested here.

In my case, I've hacked the MultiStationWeather plugin code to use the "weather" URL at all times, as I don't use forecasts.

I've got a lot of Zwave devices inside walls, so I'm being using a Vera Edge as a Zwave radio bridged to openLuup. Works perfectly once you move everything else to openLuup. Just leave the thermostats on Vera and bridge to openLuup. Makes the transition a lot easier.

Hoping to see Zwavejs talking to openLuup via MQTT one day. It's certainly possible. In the interim it wouldn't be too hard to set up a couple of Zwave devices using the Virtual Devices plugin but thermostats may be a bit tricky.

Also got ZigBee2MQTT talking to openLuup (mainly Hue devices) and some Shellies - all works nicely. You can also use Reactor with it.

You can read the openLuup info here.

Have you seen this post?

https://smarthome.community/topic/1525/forum-sysops/4?_=1713755285910

Or is this in addition to the above?

Had a look at the latest development code. Got this:

2024-04-20 18:51:28.519   openLuup.userdata:: [9111] LuaView (GitHub.master)
2024-04-20 18:51:28.519   openLuup.userdata:: [9281] Virtual HTTP Devices (GitHub.master)
2024-04-20 18:51:28.519   openLuup.userdata:: [4226] Sonos (GitHub.v2.0)
2024-04-20 18:51:28.519   openLuup.userdata:: ...user_data loading completed
2024-04-20 18:51:28.519   openLuup.init:: running _openLuup_STARTUP_

2024-04-20 18:51:28.525   scheduler.context_switch::  ERROR: [dev #0] ./openLuup/luup.lua:1103: attempt to index field '?' (a nil value)
2024-04-20 18:51:28.525   openLuup.init:: ERROR: ./openLuup/luup.lua:1103: attempt to index field '?' (a nil value)

2024-04-20 18:51:28.525   openLuup.init:: init phase completed

Had to get the house back up and running, so we could watch the TVeee.

Commented out some code:

local function log (msg, level) 
  local dno = scheduler.current_device()
  -- local mute = devices[dno].attributes.log_level    -- 2024.04.12  add "log_level" device attribute
  local mute = "something"
  if mute ~= "off" then
    logs.send (msg, level, dno) 
  end
end

Could look further but had to get the house back up and running, so we could watch the TVeee. So best I can do currently!

Yes my rookie mistake. Mixed up the function's variables being returned versus the function itself being returned. Was on the right track as "configure (dno) has fixed the issue. Thanks.

Doco corrected.

I've got something about pretty printing here. No doubt in my writings, I have made a few errors here and there but that can happen. OK on the "Generic status update over MQTT" - I'll fix that in the paragraph immediately above here.