This is news to me, considering the 'original' engineers sit right next to me. I guess I better check tomorrow morning to make sure they are still there, they were there a few hours ago :) ... View more

Have you tested out the sensor crop feature on the MV12?   https://documentation.meraki.com/MV/Other_Topics/MV_Sensor_Crop ... View more

The MV12 is too small for the t-rail kit to fit the default mounting plate. The MV12 is also too small to fit a standard 4x4 junction box. As the camera is not very heavy it can be directly attached to the ceiling tile, but I know this is not ideal. We are working on a mounting kit which will allow for t-rail mounting along with junction box mounting. I hope this will be released in the coming months. ... View more

Please contact our support team by either calling in or raising a case through dashboard. This will ensure you get some one helping you with the problem as soon as possible.   https://meraki.cisco.com/support/ ... View more

There are no mount accessories for the MV12 at this time. ... View more

We investigated smoked domes but decided not to offer one after customer interviews and testing of prototype domes. Even a lightly smoked dome cuts light transmission drastically and correspondingly decreases image quality due to the need for higher gain or slower shutter speed. To really prevent people seeing where the camera is pointing you need a heavily smoked dome.   We did not speak to any customers where the smoked dome was mandatory, more of a nice to have. We also spoke to customers that said it doesn't make a difference as people worked out where the cameras were pointing any way.   Should we get more demand for this we can revisit it's availability as an accessory. ... View more

Hi Adam,   We have a known issue currently affecting HDR on MV12 and our aim is to provide an update that resolves this very shortly. The update is currently being tested and our aim will be to roll this out to all MV12 customers once we confirm the fix is effective.    Please raise a support case so that you can be notified the moment it is ready. In the interim you can either restart the camera if you see it in this state or you can disable HDR. Based on your screen shot, I would suggest HDR is not needed for this particular camera's field of view due to the lighting conditions of the scene. ... View more

This is now fixed. ... View more

Thanks for the catch. We are working to resolve it now. ... View more

The cameras need a cloud connection as the metadata and information relating to stored video is in the cloud. Additionally, the UI is dashboard which is served from the cloud. Without access to this information and services, your client can't access a UI for the cameras, nor can the camera retrieve the metadata related to the video it has stored.   However, as the video would be streamed directly from the camera, a small backup link is sufficient to run many cameras e.g. LTE or cellular backup can run over 100 cameras if the video stream is going local. ... View more

All the analytics (computation) is performed at the edge in the camera. The metadata (results) are stored in the cloud. This hybrid approach means we can offer cool functionality like motion search, heat maps, and motion based retention with low bandwidth usage. This allows for deployments on small WAN links like cellular.   When you create a motion search, dashboard is querying the cloud's store of metadata, the table that is created at the bottom of the screen is derived from this. When you click an entry it then pulls the associated video from the camera and streams it to you.   What this means is the amount of up-link WAN bandwidth needed by a camera is variable dependent on the amount of metadata. The maximum it will be (design limit) is 50Kbps. We expect a typical camera to average about 11Kbps, and a camera that sees very little activity to average <3Kbps. ... View more

@RL   We have been investigating the use of Permanent Video Monitors (PVM) and have tested a number of different things. It is an area we want to have a solution for, but right now we haven't hit the Meraki 'simple' version which would be pleasing to use. Things you can try are Intel NUC compute sticks connected via HDMI to a TV, or Android running on a Chrome stick connected via HDMI to a TV.    Regarding the auto-logout issue, this is something we are aware of and will look at addressing.     ... View more

@cam   We may potentially offer features which take advantage of the sensors resolution in the future. As with most Meraki hardware, we build a product with headroom for future feature growth based on delivering software updates from the cloud. Today the camera is optimized for storage retention, which is typically the specification of most interest for customers.  ... View more

@PhilipDAth   For some customer deployments, 'realtime' video streaming (<500ms) is a big deal. For some customer deployments it is not. Today Meraki MV uses HTTP Live Streaming (HLS) due to its widespread browser and platform support, but this comes with some delay based on how HLS works (a couple of seconds). As other modern web technologies mature and gain wider support (for example Apple's announcement of WebRTC for Safarai here) we will look at transitioning.  The way I look at it today is that the product is only a year old and we have many things left to build. Do you want the camera for a door entry system? Well it is probably not right for you at this time. Do you want the camera to protect your school over night so you can see what happens in the morning? Well then it is a good fit. Again the family of products is still young and we know there are many form factors and options people need. These will come in time as we build out our offerings, it is just not as easy to deliver new hardware as it is to deliver new software through the cloud. ... View more

@WANKiller   1) Check out my response to @ShaneMartin (here)   2) This is not something we plan on offering. Today the Meraki MV infrastructure is managing way in excess of a petabyte of data and a billion individual video files. Taking the data off the camera and out of our infrastructure looses the associated metadata and the ability to perform all the cool things we offer such as motion search, heat maps, and motion based retention.   We don't want to offload the problem of dealing with large amounts of video to customers when we have already solved that management aspect. We know some customers want to store longer or have offsite backup, and we will investigate how to offer this in the future.   Regarding camera destruction or theft, no system offers perfect protection from a disaster. I have personally spoken to customers whos hard disks died, RAID arrays became corrupted, or even one who had their NVR stolen. In each instances, all video was lost. With MV, yes you may loose a camera, but the likelihood of catastrophic data loss is significantly lower. If camera theft and destruction is of concern, use the MV71. It is extremely rugged and I can personally attest to beating one with baseball bats, crowbars, and hammers. It is a tough little beasty.   3) This comes up now and again as an ask. My main question back is "How would you power it?" ... View more

  Here is an example of one of our testing rigs for multi monitor video streaming. What is cool about having different video walls per browser tab per monitor is you can mix type. What this means is some of the streams can be local, some cloud proxy, some live, some historical. In the picture below the single camera stream is actually a zoomed in video wall, just moving your mouse to the screen and clicking will zoom it back out to the tiled view.       ... View more

The video wall has a 12 camera limit to protect users from inadvertently creating network congestion, and to ensure browser stability on almost all computing platforms. Each video tile in a video wall is a 720p resolution video stream at the configured bit rate. At the 'Enhanced Quality' setting this will equate to a 12 tile video wall using 9180kbps.    Playback speed increases will increase the bandwidth required per camera by the playback speed multiplier. For example a camera at ‘Enhanced Quality’ settings will go from 765kbps to 1530kbps at 2x. Importantly this also includes the video wall bandwidth usage and could lead to a bandwidth requirement of up to 18460kbps for a video wall of 12 cameras at 2x or 27540kbps at 3x.   This type of bandwidth consumption is inconsequential on the LAN but due to the seamless cloud proxy, a remote user could suddenly saturate most uplink speeds at small locations. The 12 camera limit tries to put some upper bounds on the potential bandwidth consumption under normal circumstances.   As has been stated in this post, our recommend way of simultaneously displaying more than one video wall is to use independent browser tabs or windows. This has the added advantage of allowing video walls to be pinned to monitors and increasing stability as it distributes video decode over numerous threads and processes.   In our testing we have run 50+ concurrent streams on an 8 monitor setup using a 4 core current generation Xeon processor with 16GB of RAM and a dedicated NVDIA GPU. Ultimately browser stability at such loads can become an issue, but <30 streams should be achievable on most systems.     ... View more