openLuup: Suggestions

Plugins & Plugin Development openLuup
#121

I think the best way to approach this might either be to load the log into a spreadsheet and sort by device, or use a proper log browser, such as syslog provides, to do much the same thing.

It’s rather a specialist requirement and would result in LOTS of files which would be a nightmare to manage.

#122

You’re right… and what about having an option to log a specific device/plugin into a separate log?

#123

What are you actually trying to achieve? Logs are for diagnostic purposes, and adjacent contextual information from other devices and events is often critical in successful analysis.

It sounds, more, as though you need some sort of data logging of variable changes such as AltUI can provide with external databases or DataYours. It is also straight-forward to write a small startup function which will write ALL variable changes belonging to a device to a separate file. Is that more on track with what you need?

#124

AK,

Was just trying to have some specific log while debugging some plugins. But you’re right, it will be a mess to have a bunch of individual files!
You can cancel my request :wink:

#125

I’d like to see native RTSP ability. The vera boards have numerous requests to enable RTSP streaming, but vera has been awol. Given that most cameras today have an RTSP port, this would be a huge feature in openLuup as one could tie together cameras, NVRs and the universe of zwave devices.

Here’s a link to some guys doing an openRTSP project that allows embedded RTSP servers: LIVE555 Streaming Media

#126

What exactly do you see needed here? I must confess that I’m a bit puzzled by the role of video in general. Most people, I understand, use BlueIris for this sort of thing.

Vera/AltUI copes fine with displaying one or two images, but the integration trick is surely to do with triggering on events, and the like. Nothing really to do with video?

I’m obviously missing something, but if there’s already a useful library that can be interfaced with Lua then lots of things should be possible.

#127

Blue Iris is a great software NVR, but it takes serious CPU power if you have motion detection on and you have more than a few cameras, especially megapixel resolution cameras. I use an ACTI NVR which offloads motion detection to the ACTI cameras, so the horsepower needed at the server is far less (though their NVR has its own issues). So until I write an ACTI plugin, I’m stuck as all their cameras and NVR use either activex or RTSP for streams.

Why is video needed? Ultimately I suppose it’s the goal of consolidation on a single screen of devices. Something along the lines of what Imperihome offers. But you first have to be able to capture the stream. Functionality wise, camera recording could be triggered by events, and motion detection in the video could trigger devices. I look at security video as just another device that interacts with Zwave.

#128

I’ve just noticed that my Foscam camera is able to send email on event detection. I’m thinking, therefore, to add an SMTP server to openLuup which could receive these and turn them into device triggers.

Not sure how widespread this capability is for cameras? But it seems like a step in the right direction.

#129

Most cameras can send Emails with attachments. There’s usually an FTP option as well.

Acti cameras (and NVR) have their own http server that can both send and receive events, so I’m covered there. Http messaging will be the basis of the plugin I’m going to write.

#130

So I followed this guide and have had a Raspberry Docker Swarm running for a while with various containers for my home. Would love a docker/container image for openluup!

I have even created persistent storage using flocker for some of the workloads that need persistent storage.

Great work to the team btw, well done!

#131

[quote=“blahblahblah, post:130, topic:189405”]So I followed this guide and have had a Raspberry Docker Swarm running for a while with various containers for my home. Would love a docker/container image for openluup!

I have even created persistent storage using flocker for some of the workloads that need persistent storage.[/quote]

Thanks for that feedback. I keep meaning to take a look at Docker, but it’s a bit out of my comfort zone. It’s on the list, but I’m easily distracted!

#132

@akbooer,

Would it be possible to report the last Luup reload on the openLuup device? It is showing uptime right now but I think it could be useful for occasional troubleshooting.

#133

Uptime is the time since the last reload… are you wanting the date/time there as well or instead?

From a debugging point of view, the last five startup logs are available from the console window (Logs > Startup Log) and the current system start time is also there on the console at openLuup > Parameters under Status:

  "Status":{
    "CpuLoad":"3.8%",
    "IP":"172.16.42.156",
    "MemAvail":"820.2 Mbyte",
    "MemFree":"594.8 Mbyte",
    "MemTotal":"949.6 Mbyte",
    "Memory":"12 Mbyte",
    "StartTime":"2018-04-30T11:13:21",
    "Uptime":"2.14 days"
  },

There would certainly be room on the Control Panel of the openLuup plugin to put the start time, but on the Devices page there’s not much more real-estate left.

#134

Yes having the very last reload time instead of the uptime in days with decimals seems more useful to me but you are right, it is also available in the startup logs. I was just having a difficult time doing the math of 0.28 days… And yeah having it on the console would be good enough.

By the way, I tried all your commits on github from 4/23 and they fail to start on my setup…

#135

That’s very worrying. Can you start a new thread and give me some logs?

It runs fine on my RPi and iMac.

#136

[quote=“rafale77, post:134, topic:189405”]Yes having the very last reload time instead of the uptime in days with decimals seems more useful to me but you are right, it is also available in the startup logs. I was just having a difficult time doing the math of 0.28 days… And yeah having it on the console would be good enough.

By the way, I tried all your commits on github from 4/23 and they fail to start on my setup…[/quote]

Try the new development commit 2018.05.02. It has the StartTime on the device Control Panel (and, of course, in the device variables)

Still concerned that you reported a problem with an earlier commit. Let me know how you get on with this one.

#137

Sorry for the tardiness, I have been out of town and have been doing code testing and updates remotely from my iPad… not ideal. I will try to get to in by the weekend.

#138

[quote=“akbooer, post:136, topic:189405”][quote=“rafale77, post:134, topic:189405”]Yes having the very last reload time instead of the uptime in days with decimals seems more useful to me but you are right, it is also available in the startup logs. I was just having a difficult time doing the math of 0.28 days… And yeah having it on the console would be good enough.

By the way, I tried all your commits on github from 4/23 and they fail to start on my setup…[/quote]

Try the new development commit 2018.05.02. It has the StartTime on the device Control Panel (and, of course, in the device variables)

Still concerned that you reported a problem with an earlier commit. Let me know how you get on with this one.[/quote]

Just updated to 05.02 and it seems to be fine. I am suspecting that I had to reboot that VM after making so many changes to various libraries.
Thank you!

#139

Very good to hear! Thanks.

#140

A little laundry list of suggestions for when you come back and in subjective order of priority:

  1. Scene timer needs to be reset outside the scene. It is currently reset within the scene runner which is causing the next_time to not reset if the scene lua code returns “false”.
  2. Device attributes reset at luup reload. Category_num and Subcategory_num seem to not stick for custom devices (dummy sensors and plugins) and get reset to 0. Have not yet looked
  3. ArmedTripped variable not functional for security sensors for openLuup device. I would suggest running variable get on “Armed” and “Tripped” and set “ArmedTripped” only for non bridged devices in the pulse function.