The NAV frequency is 120.125, I turn the knob (One increment on the knob) it change to 122.125 (I miss the 121.125) and after 124.125, etc…
Sounds like the device is sending two events then. That is not uncommon, the Saitek rotary encoders also send events between the physical “clicks”. Try to turn it really slowly, then it should become visible how many actuations there really are.
Only solution off the top of my head would be using a script that ignores every other button actuation. Or maybe use the opposite action as up event (assuming the knob only sends two button downs, the one “up” should cancel one of them).
Thanks for help
I try the opposite action but it does not work
This is strange because it is working well with fsuicp
I am not good enough to write a script
So what happens when you turn the knob really slowly? Is there another button actuation between two clicks or not?
Make sure that you are not running both FSUIPC and AAO at the same time. Otherwise both apps will trigger the frequency change event.
I found in FS2020 control option - power management - condition level axis
this works well for the c208 fuel conditioner but I can not find it in AAO ?
I did get the reverse thrust to work with “DECREASE_THROTTLE” 
Those are not related. AAO can only use what is available in SimConnect, and there is no such AXIS_ event in the current SDK documentation. If you know the exact event name, you can add it to the AAO selection using “Scripting->Input Events and Variables manually”. Or use an RPN script.
You could try using the (A:TURB ENG CONDITION LEVER POSITION:index, Enum) variable, wrapped in an RPN script. The Enum has only three values, 0, 1, and 2, so it isn’t an axis either.
Edit: never mind, setting the simulator variable doesn’t move the lever. BVars are the only thing working for me.
Here are my Scripts for the F/A 18 heading bug:
INC:
(L:XMLVAR_AS04F_HSI_1_HDG_TK,·Number) 1 + dnor (>L:XMLVAR_AS04F_HSI_1_HDG_TK,·Number)·1·(>H:AS04F_HSI_1_HDG_TK_RESYNC,·Number)
For decreasing just change the “+”.
Hello,
I don’t know if I understood everything correctly about the profiles in AAO, but I see that on the top of the window there is the name of the aircraft when the connection is established.
Is it therefore possible to automatically load a profile, in AAO, depending on the aircraft detected ?
Thank you
Hello, I lost my Stream Decks after the update to 2.22/5.03. At first they worked, I just noticed two scripts which I use to toggle 3 key events with s single button didn’t worked fine. I was using comparisons in the scripts to make sure all switches get toggled the same way. They used to work fine, but after the update only the first switch got set. I assumed a timing problem and created new scripts using key set events instead. I replaced the toggle button with an on/off button and linked the new scripts while I was online and had an active flight. Closing the script editor and the SD editor, it was always normal that the SDs didn’t update variables no more. Usually I could fix this by disconnect/reconnect. But not this time. Even after restarting the computer no more connection. I am using a fair amount of text gauges, they all remain grey. I thought maybe downgrading back to 2.21/4.44 could fix this, but sadly the SD app refuses the downgrade.
I am running out of ideas, could use some help please.
As FBW released a new development version, my rotary encoders dont work for NAV-mode and ND1 Range any longer. does someone has the correct scripts?
Updating the SD profile will have reset the web port in settings.js to 9080. If you changed it in the old version you will have to do that again. Any changes in the plugin code have no effect until the StreamDeck software has been fully restarted (=shut down with the context menu of the SD symbol in the system tray, or a complete restart of the computer. Just closing the SD app is not good enough).
You can downgrade a StreamDeck plugin - just delete it from the plugin folder and install the version you want. But I can’t see what good that will do - your functional problems might be with SU7, not with AAO. I found a couple of aircraft where the control methods seem to have been changed in SU7.
That is what AAO is doing anyway. All configurations are managed on a per-aircraft (livery) basis, they are not global.
1 Like
I didn’t touched the settings.js. It is still at 9080. After updating the SDs worked fine for some time. I lost them inflight while editing scripts and gauges,
I was afraid you are going to say something like that. It was just me hoping getting back to the last flawlessly working version could fix the problem. I uninstalled AaO and the SD app. Set everything up anew with 2.21/4.44, also restarted the computer. “Enable web API on port 9080” is checked. Still no connection.
No doubt I ran into this mess while dealing with SU7 implemented functional problems. But I would assume my SD connection problems are on the AaO or SD app side. Buttons from other plug-ins work fine.
Anything else I could try?
Edit: I forgot to mention that AaO Axis on Saitek H.O.T.A.S and also Saitek panels and FIC work fine.
Or rather between them. This is not a proprietary connection, the StreamDeck plugin is using a simple web-based mechanism. It is entirely possible that something on your computer decided that it wants to use port 9080 now, and AAO is on the losing end. Or maybe AntiVirus is interfering.
Now would be the time to break out the WebAPI troubleshooting guide - change the port to 6080 on both ends, try the local IP instead of “localhost” in the settings.js, etc. The guide is a PDF that you can download from the AAO Weebly website.
Maybe something you did in the plugin is now causing constant errors? Can you check the Elgato debug console if any error messages are visible there? Did you check other SD profiles?
I’m on the Dev version from a couple days ago and the below works:
NAV Mode Left
(L:A320_Neo_MFD_NAV_MODE_1,·Number)·0·>·if{·(L:A320_Neo_MFD_NAV_MODE_1,·Number)·1·-·(>L:A320_Neo_MFD_NAV_MODE_1,·Number)·}·
NAV Mode Right
(L:A320_Neo_MFD_NAV_MODE_1,·Number)·4·<·if{·(L:A320_Neo_MFD_NAV_MODE_1,·Number)·1·+·(>L:A320_Neo_MFD_NAV_MODE_1,·Number)·}
Range Inc
(L:A320_Neo_MFD_RANGE_1,·Number)·5·<·if{·(L:A320_Neo_MFD_RANGE_1,·Number)·1·+·(>L:A320_Neo_MFD_RANGE_1,·Number)·}
Range Dec
(L:A320_Neo_MFD_RANGE_1,·Number)·0·>·if{·(L:A320_Neo_MFD_RANGE_1,·Number)·1·-·(>L:A320_Neo_MFD_RANGE_1,·Number)·}·
Weeks ago the above was not working on the Exp version, so if it is not working they make have merged the Exp with the Dev version
Thank you very much, i‘ll give this a try
No, these are the same scripts i‘ve used so far and which dont work now. Do you have the alernative ones?
Maybe I should have done it step by step to localize the problem, however, I switched the port number to 6080 and deleted all buttons I edited or created closely before the communication loss. There is still a different behaviour than before. When I start MSFS, AaO “Start automatically” and “Connect automatically” enabled, AaO stays at “Waiting for aircraft data” even when I start a flight". When disconnect/reconnect AaO is getting the aircraft template and then all Lorby SD gauges getting updated.
So, if you could advise on how to improve the aircraft detection?
Anyway, this is a minor problem, I can fly again, great support as always, thank you.
That doesn’t work at all for me. Is the exe.xml method broken in SU7?
even when I start a flight
How long does it take from AAO start to this point? And what is the default camera mode that you are in when the flight starts?