Stumped

sentry07

I've got an old AMX system (NI-3100, MVP-9000i panels with in-wall docks) that is running two rooms at a university. The rooms are combineable. About 4 months ago, I put in a logging feature that logs every button press on the two panels, system configuration changes, device power on and off, the whole works. This was to diagnose projector issues but it has caught something else that is boggling my mind. Starting on 3/17, at around 7:30AM, it shows that TP2 (10002:1:0) pressed channel 255. Then again at 8:30AM. Then again at 9:30AM. All exactly one hour apart, to the second. In code, 255 is the power off button so that room shut down or tried shutting down. The very strange thing is there were no other button presses, which would make this impossible for a human to have done it from the touchpanel itself because you can't get to the power off page without pressing buttons. TP1 (10001:1:0) has never done it. Both panels are the same model, MVP-9000i, with the same TPD project loaded on them. The events happened every day from 3/17, at around the same times, 7:30/8:30/9:30AM EXACTLY 1 hour apart, (7:28:53, 8:28:53, 9:28:53 for example), until 3/23. On 3/24 they stopped and the logs don't show them since then. I've scoured every line of code, every include, every module, and I can't find anything that would emulate that panel pressing 255. There are automatic shutdown features, but they happen at 9:30PM and it doesn't press a button, it calls a Power Off function.

Please, for the love of god, can someone explain this? Is there something in the MVP-9000 that can be set up to do this? Is there something in the docking station that can trigger button channels? I'm pulling my hair out trying to figure out what was causing it and there's nothing.

Danny Campbell

I'd first look in the program to see if there is a DO_PUSH command for tp1 channel 255 somewhere.

sentry07

I've run a file search on every file I have and there is nothing that does a DO_PUSH on channel 255.

vining

are there any compiled modules that you can't access the source for? channel 255 is a common feedback channel for some modules and maybe you have a device combine tying a virtual to TP1 port 1 somewhere.

sentry07

I have all the source code. All modules are using virtual devices that are combined with ports other than port 1 on the touchpanels. I grepped all files for "255" and any constants that were set to 255. I grepped for DO_PUSH. I grepped for everything I could think of. Nothing in the code is causing TP2 to push channel 255.

vining

Well then I would change channel 255 on the to another channel number tha doesn't trigger code. Add code for that new channel number to just trigger a logging routine and see what happens. If 255 still triggers and there no longer is a channel 255 anywhere on the panel it has to be code. If 255 never triggers but the new channel does then it something goofy going on with the panel. I don't know what else to try if you've search for and eliminated all other possibilities.

ericmedley

Occam's Razor definitely applies here. The seeming and suspicios nature of the regular time of the button pushes says it has to be code. The fact you cannot find it is what is suspect. It's there. Like Vining says, it's probably buried in a module that is triggering the SNAPI channel. I'd suggest setting up a little test bed where you can set the master's time to just prior to the known event. (you'd need to turn off the Network Time Service so the master will let you set it to 6:59 or whatnot) comment out all the moudle, then one by one bring them online and see which one fires the button push.

John Nagy

Well, I'd say the precision of the event timing means it has to be code, unless it's a device.You know, ones that have clocks. Like panels or Netlinxes. Or something else in this system that has yet to be described. Which is pretty much everything. All we know is 9000i panel(s) and a 3100.

I note in passing that many AXB devices generate a 255 upon connection or disconnection. Other things do other things.
A friend had a favorite diagnostic analysis: "It's ether a part or a component." That was before "Code" and "Firmware" and :"Hackers" but you get the idea. We've been given enough information only to agree with the OP that it makes no sense.

That said, I heartily agree with Vining. If it hurts to look into the sun, look away.

sentry07

John Nagy wrote: »

I note in passing that many AXB devices generate a 255 upon connection or disconnection. Other things do other things.

That's really all I was asking for. Are there devices that can generate a 255 push without someone pushing a button? I know it's not code. I've spent a really long time and have gone to great lengths to prove it's not code. I wasn't really asking for help diagnosing code. I just wanted to know if hardware like a touchpanel or something could be set up to do a push on a certain channel when something happens, like reconnecting to the system or on a schedule or something.

John Nagy

sentry07 wrote: »

I just wanted to know if hardware like a touchpanel or something could be set up to do a push on a certain channel when something happens, like reconnecting to the system or on a schedule or something.

Yes. Things like synch sensors, power sensors, IR pickups, and others may generate a PUSH upon connection to axlink, and 255 is the typical push on that event. Also motion sensors in panels (the 9000i doesn't have them) can be set to any address, but often default to 255, port 1. Which generally results in an unexpected PAUSE to some device being controlled, as the original default location of PAUSE in sample code was often 255. Which is the main reason we moved off of 255, basically for anything.

THAT said, your trace showed that 10002,1,0 was pushing 1,255. The devices I mention above are not capable of aliasing a push to appear to come from a panel. And the precision of the time to the SECOND makes it unlikely anything not processor-activated could be pushing it. Which lets most of my list off the hook.

You might move the panel to another address and see if pushes would appear to still come from the old address, or from the new panel address. It would tell you a lot.

TonyAngelo

sentry07 wrote: »

I know it's not code. I've spent a really long time and have gone to great lengths to prove it's not code.

No offense, but this statement alone makes me think it's probably code.

a_riot42

There is the possibility, a remote one, but still, that the panel overlay is failing and triggering phantom button presses. Its happened to me before, and I couldn't figure out where they were coming from to save my life. You wouldn't think you'd see them at precise hourly intervals, but who knows. A push can also live in the command output field in the TPD file I think. The other thing that could happen is an error in the code that is doing a do_push on $FF so a search for 255 comes up dry, yet $FF is the same as 255. Could someone have forgotten the atoi command somewhere?
Paul

ericmedley

a_riot42 wrote: »

There is the possibility, a remote one, but still, that the panel overlay is failing and triggering phantom button presses. Its happened to me before, and I couldn't figure out where they were coming from to save my life. You wouldn't think you'd see them at precise hourly intervals, but who knows. A push can also live in the command output field in the TPD file I think. The other thing that could happen is an error in the code that is doing a do_push on $FF so a search for 255 comes up dry, yet $FF is the same as 255. Could someone have forgotten the atoi command somewhere?
Paul

Bad TP Overlay triggering button pushes: This has happened to me as well. In my case it was lowering a projector screen by ghost-hitting the screen down button on certain pages/popups where the button was in the exact same location. In this case, while possible, I think the fact that it happens at the exact same time and at very conspicuous times like 7AM on the dot points to something in code. I'm still betting it's an errant do_push hidden in a tko file where he cannot look at the source code.

John Nagy

Again, swapping out the 9000's addresses would tell that, when the problem moved with the panel or didn't. "Basic" troubleshooting... form a hypothesis of what is causing it, change something that would exhibit a changed behavior if your hypothesis is correct... retest. No change? Hypothesis wrong. Lather, rinse, repeat.

None of which matters now for the OP, as it isn't doing it anymore. This discussion is now more about approach.

a_riot42

Russian hackers?