Anyone using Omnitouch7 screens with "heavy" IP camera traffic?

[jcd]

Okay, so I know the real answer here is, "Leviton screwed HAI and left users and dealers high-and-dry..." but I am nonetheless seeking a resolution on the following:
 
I've got an installation with "heavy" IP traffic - meaning an OmniPro II (pretty much saturated with ~1450 lines of code) connected to fifteen (15) Omnitouch 7 screens and nineteen (19) IP cameras. The Omnipro only allows event code to address ten IP cameras in terms of camera pops on the touchscreen, though all nineteen cameras are addressable manually via the touchscreens themselves. Anyway - it's a lot of IP traffic, especially given the MJPEG limitations of the Omnitouch 7.
 
I have all PoE devices connected on the same 48-port PoE switch, so to avoid any cross-switch fabric latency - since the Omnitouch 7's seem very sensitive to latency - but I'm recently having lots of issues getting IP cam screen pops to work reliably across all the screens. It's like the Omnitouch 7 looks for the camera, and if there is any latency, it just gives up and displays a "Connecting..." message. All cameras ALWAYS work in the smaller preview window, but getting them to pop in full-screen mode is iffy. I've found if I unplug the Omnitouch 7 and replug, it works for a while, but then starts failing again. 
 
I guess my question is: have I taxed the horsepower of the OmniPro II to the breaking point? Maybe it was only "designed" (I use that word lightly) to use 3-4 Omnitouch 7 screens, or maybe only a few IP cameras?
 
Does anyone else have any experience with a fully loaded system as described? And/or any ideas on the constraint here causing the camera pops to be unreliable?
 
Other than this issue, the Omnitouch 7 screens all function perfectly fine and display solid connectivity and responsiveness. Unfortunately, the camera pops are ~75% of the value in this setup.
 
Many thanks!
Jcd

 

[BraveSirRobbin]

I don't have a solution for you regarding the Omni, but for the IIP cameras, do you have their setting set to minimize traffic such as resolution, frame rate, etc...?

 

[pete_c]

Personally here also do not have experience with a set up as large as yours.  
 
My guess is that the OmniTouch 7's just cannot handle multiple IP streams and the panel only does MPG captures or MPEG streaming.
 
Here have installed Omnitouch Pro on Atom based tabletop tablets and they are much faster than my Omnitouch 5.7e screens and handle video really well considering how primitive it is.  
 
I guess my question is: have I taxed the horsepower of the OmniPro II to the breaking point?
 
Well yes and no.  The Omnitouch analog video board / Omnitouch hub could do this but it was all analogue with standards from years ago.  (SD analogue cameras).
 
You are proxying the video through the OmniPro 2 and converting the video to 640 X 480 with MJPG or still captures.  Multiples of these even at SD will slow down the OmniPro 2 panel.  Solution would be to by pass the panel on the touchscreens for viewing of the cameras doing RTSP.  I do not know of a way to do that with the Omnitouch 7's.  
 
 
Maybe it was only "designed" (I use that word lightly) to use 3-4 Omnitouch 7 screens, or maybe only a few IP cameras?

 

[jcd]

Thanks much fellows.
 
As to the question about frame rate and resolution, I confess that I do have these maxed out at 30FPS, highest quality, etc. I guess I figured I wanted to get "what I paid for" in terms of the camera quality and I assumed that the screens could handle it. Oddly enough, this problem only popped-up recently and the only thing I could think of that changed is that we did have one camera fail and replaced it with another - though the MJPEG stream and quality were the same between the two.
 
In any case, I'll certainly try to ratchet-down the frame rate and resolution to see if that buys me more reliable performance. I'd rather the reliability and utility of having camera pops than to fret about the resolution - after all, the Omnitouch 7 resolution is not awesome anyway, so I'm sure not much will be missed at lower settings.
 
I'll report back with results, and thanks again!

 

[pete_c]

If you proxy the cameras through the OmniPro 2 via configuration in PCA it is hard to tell what resolution / frame rate I am seeing on the OmniTouch 5.7e.
 
The proxy that the OmniPro 2 is resource intensive because it used to convert the video to SD.  Not sure what it is doing today.
 
Not sure what you see on the Omnitouch 7.
 
My doorbell resolution is almost 3MP and the picture was way too small so I edited the screen with designer to have it fill the entire width / length of the Omnitouch 5.7e.  
 
It used to be that it converted the image to SD with a slow frame rate.  With most current version of PCA / camera settings you cannot tell these days because there are no settings.
 
I am thinking if you directly link the camera to the Omnitouch 7 then you will have the resolution of the camera.  I do that with the Omnitouch 5.7e's but it is really slow compared to running OmniTouch Pro on a Wintel tabletop touchscreen (which has only a 800X600 resolution) and does OK playing back 720 resolution.
 
This week will give a newer Windows 10 higher resolution tablet a try with the OmniTouch Pro software.

 

[jcd]

I am thinking if you directly link the camera to the Omnitouch 7 then you will have the resolution of the camera. 

 
Hi Pete - yes, though I think the OmniPro II or the Omnitouch 7 does downscale to SD, as you seemed to suggest.  I say this because I had some cameras setting the MJPEG stream to resolutions much higher than the native Omnitouch 7 can support, and they are obviously downscaled. So this conversion, plus the high frame rate, plus nineteen cameras trying to pop on fifteen touchscreens may just be too much to ask this system.
 
I went into all of the native IP camera configurations today and ensured two things:
1) the camera resolution feeding the MJPEG stream is at SD-levels and not 3-4-8+MP (most of the cameras are 4MP); and,
2) the frame rate is about 5-8fps (I had all of them set to 30, so this is a definite reduction!)
 
BTW, I still run H264/H265 in the main streams because these cameras all feed into a Synology Surveillance Station server - hence all the cameras have multiple streams: HQ for the Synology, and dumb quality for the HAI system (by necessity).
 
So far-albeit with only a few hours of testing-things do seem to have improved. I'll see if things stay stable over the next few days, or if they degrade again...

 

[pete_c]

Yes noticed that the PCA / Camera / Links are different that earlier versions of the links.
 
Originally it was an SD Axis server configuration (which I had running) but SD.
 
Here the newer Hikvision IP cameras (well including 4K) do RTSP and ONVIF.  I used ONVIF for the MPG stuff.  That said I leave the cameras to provide HD on main stream and SD on secondary stream.  
 
With the PCA / Camera configuration links it was just taking the MPG still capture stream whatever the resolution / frame rate and knowing that the PCA Proxy was taking it down to SD.
 
The camera pop up is so slow on the Omnitouch 5.7e's it produces the image slowly from the top to the bottom.  I  have too gone to a JPG image for the backround.
 
Thinking that the Omnitouch 7's were the last add.  Can you edit or create new configuration of the OmniTouch 7's using Leviton / HAI automation studio?
 
Here changed the camera pop up window to utilize the entire width of the screen providing a nicer picture but slow.  Here my doorbell pop up video doesn't work.
 
IE: If doorbell rings then pop up doorbell video.  
 
Thinking that Leviton changed the firmware to make it work for the OmniTouch 7's and overwrote the code for the Omnitouch 5.7e's.
 
Just looked at one Omnitouch Pro running on my tabletop touchtablets which I customized using HAI Automation Studio.  
 
The front door Hikvision doorbell wireless camera image is crispy (looking a bit HD versus SD) and pop up is way faster than on the Omnitouch 5.7e's.

 

[jcd]

Hi Pete - I cannot speak to your question about Automation Studio as I have not used it.  I was considering making an investment in Bitwise templates and time/training - until I learned that camera pops were one thing that Bitwise customization could NOT accommodate (i.e., would be lost moving from the native Omnitouch 7 firmware)
 
Here's an update though: I am back at square one.
 
Even after I "downgraded" the resolution and frame rate settings, I'm seeing the same symptoms, which are that the Omnitouch 7 screens work fine after a hard reset (unplugging the PoE cable) but only for a time... after a while they are incapable of displaying a full screen image when invoked (i.e., camera pop) in the PCAccess event coding. All screens remain able to display the preview image, but when attempting to show full-screen - either through PCA events or manually at the screen itself - they only display "Establishing Connection..."
 
Pulling the plug fixes the issue when they reboot, but only for a few hours or so.
 
Is there a buffer or something on the OT7 which is not getting cleared and thereby preventing the full-screen display, I wonder??  I just find it strange that they work reliably for a few hours when unplugged/replugged, then degrade. It makes no sense.
 
FWIW, I should add that there have been NO changes to the PCAccess code. Yet for whatever reason, this problem has cropped-up only somewhat recently, and is repeatable consistently as I described above.

 

[LQtechvn]

OT7, OT5.7E, OT Software have same a problem is lost connection and show connecting... forever.

 

[pete_c]

Here put in a micro server / firewall between the Ethernet interface on the OmniPro 2 and the rest of the network. 
 
This narrows down the amount of traffic hitting the panel and I can QOS it a bit.
 
One of the early issues with the Omni Pro 2 panel was too much traffic hitting the Ethernet port because it was too promiscuous.
 
The panel is still running via a serial bus and the ethernet was a late add on.  That said too much Ethernet traffic will take down the serial bus.
 
You could consider maybe looking for inwall Android devices and run OmniPro software like NQLink mentioned above.

 

[jcd]

This narrows down the amount of traffic hitting the panel and I can QOS it a bit.
 
One of the early issues with the Omni Pro 2 panel was too much traffic hitting the Ethernet port because it was too promiscuous.
 
The panel is still running via a serial bus and the ethernet was a late add on.  That said too much Ethernet traffic will take down the serial bus.

 
Thanks Pete. I am running managed switches, so your QOS idea is a good lead to explore. 
 
I was not aware of the Ethernet port issues with the OP2 (other than overall sucking) - and didn't realize that too much traffic could take down the serial bus!!!  That last point alone could help explain other random anomalies that make us scratch our heads (the polite euphemism
 
As to the in-wall tablet and other paths... hardware cost is an issue, software training is an issue, and continuity is an issue (i.e., we've gone through OmniLink, Space and prior iterations, HomeSeer apps, Myro Home, etc.)  If HAI had a future state I'd consider, but I have a significant sunk cost in what's already deployed, so this isn't feasible, or at least there is no appetite for it let's put it that way. Trying to squeeze everything we can out of a native setup.
 
Thanks again to those who shared thoughts on this topic - very much appreciated!
 
Cheers,
Jcd

 

[pete_c]

A managed switch will not work; tried that a few years ago.  Only a router worked.  Try any router you have around.  
 
Here went to a mini travel router with OpenWRT powered by the panel.

 

[StarTrekDoors]

A managed switch will work but you'll want to isolate only the specific traffic you want to go to the OT7's and you need to severely limit that traffic.  QoS is a network technology that will not "fix" the issue with the OT7 because the issue is with the OT7.  It does work however and you can schedule restart events in your managed switches (if they support it) to clear the memory leaks and lag issues.
 
The way an OT7 works is that is simply receives a message from the OP to connect to the IP video source on an event, or when the camera icon is activated on the OT7 (the URL info is stored locally on the OT7), which also allows it to connect to the IP camera's IP address; the Omnipro has relatively nothing to do with video capability other than the triggered event.
 
Many servers and PC's have a high-end network interface card that has onboard processing power so removes the difficult task of looking at every network packet from the system's CPU/OS to check packets on the network interface itself leaving more CPU for applications.  In the case of the OT7, it is no dedicated network processing capability so it must use it's CPU to read those packets, as well as display the GUI, process video Codecs, and to look to see if the next particular packet is destined for it.  On a network with a lot of network traffic, the OT7 gets behind because it is trying to do everything with very limited capability which is why many tablets operate significantly better because they have more processor and advanced or dedicated video processing.
 
For those that don't understand the technical terms; imagine you are in your car trying to get onto a busy highway that is bumper to bumper and you are looking for your friends car because you have information for him but you also have information you need from all of your other friends that are on the highway which is also crowded with other cars whom you do not know.  You have to check every car as it passes to see if it's your friend's car plus you have to manage your own car and figure out when it's safe to get onto the highway while still looking for all of your friends and you are busy constantly painting a picture/video. After a while, without help, you get tired and so... lag in reactions, your paintings don't look so good or you never get to painting another picture, and you missed in checking for your friends' cars.  Cars are packets, your friends are the packets destined for you, and help looking for specific cars (packets) is a dedicated network interface card with onboard processing that is missing on the OT7 (due to a couple of dollars it might add to the price).
 
By limiting the amount of network traffic the OT7 "sees" at it's network interface, the less load it has on it looking at packets and the less likely it is going to get behind. Having a dedicated switch does nothing to help if it can see all the traffic from other switches and traffic unrelated to the OT7.  In Pete's case, he substituted a router for a L3 managed switch which worked for him and is a great alternative for those without good network hardware on a busy LAN. 
 
As many have suggested, a tablet works much better. From personal experience, is easier to use also although I have a few OT7's in my own home also.  BTW... some customized GUIs and graphics that Leviton shows for the OT7 are NOT possible and simply marketing. Higher resolution is not a capability nor high definition color renderings are possible and some GUI layouts shown are possible at all (and Bitwise OT7 does not provide the same OP functionality).  Leviton does not make this tablet, they only sell it. The generic tablet has more features at less than half the price from the same manufacturer with support for PoE plus the Leviton app so may be a future alternative but will still have the same network issues on a high traffic LAN [highway]       
 
Anyway, segregate your traffic, limit packet volume, schedule restarts, and you should have a better experience.

 

[sjht]

I found that telling my managed switch to limit the Ethernet connection to only 10/100 seemed to have solved the issue for me. I removed my router in front of it long ago. If the switch is 1G, the OP2 seems to have issues with this. I also was told about this by the folks at Worthington Distribution.  Maybe it doesn’t work for everyone but it has worked for me,  The Worthington folks also told me you could put an old switch in front of it that was not a newer 1G type and that would help. SJ

 

[pete_c]

Yes here tried an old hub first then went to trying my L2 managed switch with said used port set to 1/2 Duplex 10Mbs and still had the same issues many years ago.
 
Current microrouter is 100Mbs in / out which then connects to a managed L2 switch.