samuelharris

I run a small security setup in Chicago using Axxon One across a few cameras at a shared building, and I have been building a simple web app with a no-code tool to log incidents and pull clips for the property manager. The plan is to keep the camera side in Axxon One and have the web app handle the incident records, but I am not sure how cleanly the two sides can exchange data without custom work on the PSIM side. My main worry is that the no-code builder will not handle the integration well and I will end up rebuilding the logging in PSIM anyway. I have only read general information online about how no-code tools connect to surveillance platforms, so I do not want to overcommit before I understand the limits. Has anyone here linked a no-code web app to Axxon One or PSIM, and what worked or failed for you?

Arron, when you say the logs show nothing, is that the app-side logs or the server-side ones? The generic AxxonNet error and the app's "authorization problem" may have different causes, so checking the VMS server logs around the connection attempt could separate a network path issue from an account/permission one. Also worth confirming whether direct connection uses the same credentials as AxxonNet. The support route above is likely the fastest way to get a definite answer.

Specific false-alarm numbers are hard to generalize, since results depend heavily on camera placement, lighting, crowd density and how the vendor defines an event. For a thesis, published benchmark datasets are usually more defensible than anecdotal figures, because deployment reports rarely state their test conditions. Ask vendors for precision/recall at a stated operating threshold rather than a single "accuracy" number, and check whether the reported rates were measured on-site or in demo footage. Also worth noting that event venues vary a lot in density and occlusion, so any single figure deserves caveats.

The split between monitor, archive, and analytics streams seems like the most practical lever here. Using a lower-resolution stream for live viewing while recording the higher-quality one keeps the archive useful without making the monitor path expensive. Auto-selection also makes sense where camera loads vary, though it would be worth checking how quickly it switches and whether it can cause visible quality changes during motion. Does the load reduction come mainly from decoding fewer pixels, or is there also a gain from avoiding duplicate processing of the same stream?

ChangeConfigRequest is the right idea for enable/disable, but arming usually lives on a different service than the video channel config. Check the device's capabilities first, since not every camera exposes an arm/disarm action, and then look for the specific request that carries the armed state rather than editing channel config directly. If the config schema has an armed flag on the channel or device object, use that path, but confirm the field name from the service definition you're compiling against. Sharing the request type you used for enable would make it easier to point you at the matching arm call.