possible collaboration with motionEye/motionPie developer on GUI/motion.

[piecam]

HI silvanmelchior,

I have tried a few times trying to bring robert and ccrisan. The following is the newest attempt for me to get ccrisan involved. https://github.com/ccrisan/motionPie/issues/184

I don't know much of essence of development; althrough, robert kinly explained me a few times the vision and focues of two projects might be too apart to fusion together.

I still feel that ccrisan's gui is more fluid and could be leveraged. Whether we leverage supporing for usb cam or not, doesn't matter. It can always come later. However, it may simply use on of motion thread-1.conf to control this pie cam via mmal api (not from /dev/video0, this is motionEye/motionPie's usage).

Hope you guys don't feel this in anyway offending or wasting you guys time. Just want to pass on some of thoughts and it may be a good time if you can spend a bit time setting up one pi with ccrisan's project and see whether we can get those piece in.

ccrisan mentioned that he's willing to help out if someone doing this; although, he himself has other priorities.

Again, many thanks.

[spikedrba]

Hi @piecam,

just speaking for myself here,

I largely agree with you at the goal level, rpi-cam-web could use a more "fluid" interface, before Robert pushed all his great changes I was pretty much trying to implement my own thing based on picamera and looked at building on top of motionEye. However just like ccrisan said, integration with anything else but Motion is a big job and, in my conclusion, not one worth pursuing. The design is just too rooted around motion to the point that we'd be ripping out so much code that we might as well start from scratch.

And that was my plan before I did further testing and figured that picamera wasn't going to give me the level of perfomances I was hoping for (based on my experiments and measuraments load/cpu usage is substantially higher than raspimjpeg). Therefore I fell back onto RPi_Cam_Web_Interface even tho I can't help much because I don't speak C that much (trying to fix that). We could of course overhaul the web interface, I'm sure folks would be willing to accept patches and as much as I'm a python guy, this is never going to be a massive webapp so php will do just fine, if anything maybe reorg the code a bit and bring in a templating lib to avoid mixing html and code.

Also regarding your comment about this project using Motion, see #56 , there's really no point is sticking with that and hopefully if @silvanmelchior or @roberttidey can work some magic out raspimjpeg will be implementing its own soon, which imo is the right direction.

just my 2c, would love to see this growing and all of us helping each other.

best,

Spike

[roberttidey]

I agree with those comments. There are so many fundamental differences in the basic approach and coding and run time environment that trying to 'merge' code is very difficult and would end up in more effort than just adding the functionality / interface required.

It sounds like ccrisan is contemplating utlising raspimjpeg as a side tool for previews which is fine but I think we are talking about deeper ideas here..

For the RPi Cam Web Interface we should focus on the motion vector detection initiative and cleaning up / adding functionality to the Web interface.

Certainly it would be good to move to a cleaner template approach on the web side. I originally just started tweaking the php code and that has been pushed further than originally intended. Similarly the overall config and capture management could have benefited from a simple database approach. Changing will require a fair bit of effort which I'd be happy to contribute to. We would have to consider whether this is a fairly clean restart as maintaining compatibility would add quite a bit more complexity and effort.

Apart from the raw technology used it would be good to get an idea of what improvements in the function / operation on the web side are thought most desirable. If we can interest someone who has good experience on UI and styling that would also be good.

A couple of bits that I'm quite interested in are Organisation / Filtering of captures by date A front end that can tie multiple RPi Web Cams onto one overall site

[spikedrba]

since we're talking, here's where I'm at with this.

I'm working on a security camera system, and I'm not talking about a weekend DIY fun project to monitor my hamster, I'm talking full on professional video surveillance but open and programmable based on the pi. I've spent a ton of time building enclosures, testing lenses and all kinds of things (taking apart commercial cameras) and while I'm nowhere at a skill level of someone that built the pi's camera board or pi itself, I'm reasonably comfortable I can build a security camera that beats hands down 99% of the products out there (would love to be proven wrong, I'm new to this after all, just excited about it), with the only corner case being low light vision if you're not using an IR module, but, it's a case that don't even make sense imho if you're serious about your installation. The sensor could be bigger (at least 1/3", that's what is in most sec cameras), but the 1/4" in the pi camera is so good that I can't honestly tell the difference (again would love to be proven wrong).

I'm planning to base this on raspimjpeg and I was going to build the frontend in python with Bottle (microframework, light and simple, but this is not a complex app). Roughly I wanted to have:

• panel to view the camera streaming
• preview section with proper sshots, ability to name/tag things,
• panel to choose from other cameras
• settings protected by password
• scheduler (just like the current one) + a retention thing to rotate video if running out of space
• manual setters (to lock settings as discussed in other threads, this avoids false motion from light changes and gives clearer recordings)
• monitor for stats/temp and storage
• alerts (email + possible integration with twilio to send sms or whatever)

In terms of techs, as I mentioned I was going with bottle+bootstrap+jquery for the frontend, python-daemon for the scheduler and other maintenance bits.

I've yet to work out a good way to have everything talk to each other, not sure right now if the FIFO is the best approach, but haven't thought it through.

I also have already protyped a PIR sensor that combines with the motion detection. This is useful to reduce false positives since the PIR will confirm the presence of a person and avoid clouds or threes or something causing a lot of false motion. It works really well in my tests Last but not least I was toying with avahi autodiscovery, so that if you put a bunch of cameras on the network they'll find each other and automatically add themselves to the panel.

I have a longer list of stuff :), but I'll leave it at that for now. I can't offer much in terms of work on the C side, but I'd be happy to work on the web part, either that we stick to php or switch to python. With python we could avoid using a webserver altogether and just use paste or something, Apache as it stands takes like 30% of the cpu when I'm viewing the stream (switching to nginx would help, I know there's a PR for that).

[silvanmelchior]

I can just repeat what have already been said, I think a merging is not possible without giving up a lot of code.

@spikedrba: your project sounds pretty interesting, I'd love to see some results :)

[spikedrba]

@silvanmelchior what kind of results would you like to see? most of the time up to know was spent on the hw side. Building a professional sec camera turned out not to be easy and by no means I think it's a done deal, however I think I've figured out enough around components, lenses, casing, POE, sensors, IR light etc to be in good shape. A lot of that project is also around education, 80% of footage given to the cops after an intrusion is useless because people mount cameras improperly (even vendors) so I spent a lot of time documenting best practices for example.

Right now my next priority is to work on the frontend, which is where this conversation comes in I guess. I could, and would be happy to, contribute to RPi_Cam_Web_Interface, but if I had a choice I'd rather do it in python since that's RPI's language of choice and I need it anyway to interface with the PIR sensor (and the rest to come), not to mention it'd come easier to build a real daemon for the scheduler that logs to syslog etc, ie make the whole thing a first class citizen.

I completely understand if this isn't interesting/compatible with your direction and you'd rather just incrementally improve of what's there, it can make a lot of sense to do that. Or if you'd rather just defer and keep going and wait to see what I push out in the next few months, that makes sense too.

[piecam]

https://bitbucket.org/ccrisan/motioneye/wiki/Home

HI Guys,

I am so happy that I have enacted this discussion. That's enough for me to be happy with. :-)

Anyway, even if merging two projects is not a reality, wouldn't it be possible, just borrowing some of ccrisan's GUI portion of code for our future GUI? I am not saying his code is super, in terms of resource efficiency(cpu/mem, etc), but it feels pretty light and with nice choice of components to make that user GUI nice and fluid. I believe it's based majority on python and light python(kind) server. I dont' know details.

So, even if we are breaking away from motion, his GUI part of code might be a good reference.

If someone with skills can set up a pie cam with ccrisan's project and play around it, then poke through his code components from that link on the top, you may find it's worth giving out a try.

I has email notification, NAS mounting, scheduler, etc as well.

Just my 2 cents.

Thanks again, for your great work.

Best regards,

[spikedrba]

Hi @piecam,

what makes up his GUI is a jinja2 template which apart from being parsed will entirely render client side and so there's not much "lightness", it's just a template. The python server would not be reusable, tornado is a very performing aync http server/framework, not really a web dev framework (as compared to say flask/bottle/web2py etc). In our case it's not like 100K users are all going to watch the same stream at the same time, so it doesn't really matter, we just want something lightweight that doesn't stress the pie, but besides that I'd rather use something that was designed to build webapps and has provisions to access a db (sqlite for example) and has middleware for user auth etc. That should make developing and maintaining a frontend much easier.

And all that said, we can still reuse his stuff (the template) since bottle for example will allow you to plug in jinja2.

I'll try to take a look at starting something next week as a PoC.

thanks,

Spike