Lorby_SI

Maybe your firewall is intefering? Letting the data pass one way only? To be on the safe side, you should create firewall rules that allow all traffice through the TCP port that you have configured for the WebAPI - in both directions, incoming and outgoing. Creating a rule for the AAO app itself is the wrong way to go, that won't work. Sorry, my bad, but this was B.S. When you are seeing data on the StreamDeck, then the WebAPI and the connection are both fully functional. The SD plugin is sending requests to AAO and gets the data in the response. So the API is working both ways. You are certain that the buttons on your SD are working? No others plugins that could interfere? The easiest way to check would be using an empty profile and creating a single AAO "Button" Action on it. This should be picked up in AAO when you open the "Add Button" dialog (same as with a joystick or button box, but it would show "WebAPI" as the source).

Sounds strange, never heard of that before, sorry. The only situation where this does happen is when the profiles call scripts and the user forgot to import the script package(s) into AAO...

That assumption is wrong. The checkmark does not indicate that something is "active". It is just local to this dialog, the checkboxes are there for selecting the addons that you want to change the web address/port for with the buttons below the list. It is disabled when you run the StreamDeck software, because in this state, AAO cannot change the Web Address in the plugin's config file (=the buttons wouldn't do anything) Please explain a bit more what you mean by that. What does "writing back" mean, what do you expect to happen when you do what exactly? When the WebAPI works one way, it works the other way too - this is one single mechanism.

I would still use my autoscript. Since the battery LVar apparently has 10 as the "ON" value, the script would look like this: (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (EXECBAT:C:\myfile.bat) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }This script will always start the batch file every time the Battery switch goes from OFF to ON. It will also start the batch file when you connect AAO after you've already switched to "ON", because that is the state that it is looking for. Initially, both LVars are 0, so the script won't fire. When you click the battery switch ON, the LVar changes to 10 and the if is executed. And since you only want to start the batch when the battery is turned on, the script checks for the value "10". There are probably a dozen other ways to script this, and there are alternatives too. You could create a CONVERSATION type script file and start this when you start your flight. In such a file you can make the logic wait for certain things to happen, then proceed with doing other stuff. AAO users are implementing thier own first officer and/or flight attendant with this technique. In this case, the line that waits for the battery switch would look like this: (...some code...) [(L:VC_Battery_SW_VAL, Number) 10 ==] (EXECBAT:C:\myfile.bat) (...more code...) That CONVERSATION you start at the beginning of your flight (via Autoscript), and it will wait for the battery switch.

As I wrote above, you cannot catch the "click", that is not possible with LVars. You can only react to the animation LVar changing its value (=observing the result of the click - that is not the same). Please specify what "the first click" actually means. Do you mean every change of the switch = both ON and OFF direction? Or only "ON" because you always start in cold and dark mode?

I'm sorry, but I have no idea what you are doing there. Why aren't you just using my script? Lose the // comments. They are bad form and only slow down processing for no purpose. You know what your own script is doing, you don't need a comment to tell you. (L:MyVarBat) is AAO internal, it doesn't have a unit. Lose the ", Number" (L:MyVarBat) MUST always have the same value as the (L:VC_Battery_SW_VAL,·Number). It serves as a reference, so the script knows when the Battery LVar from the sim has changed. OK? That's the whole "trick" here, it prevents the script from just running every time. You cannot just set it to whatever value you want (why 10? why 20?) LVars don't have to be initialized. Their life begins when they are first used in code. So (L:MyVarBat) is 0 every time AAO is initialized (restarted/connected to the sim/a script is alterted/ etc.)

You cannot "intercept" an LVar - they are just values, stored in the sim under this name. If this LVar keeps its value, you can write an Autoscript that compares it with your own reference value and then triggers some code of your own design - like calling a batch file. But if the aircraft designer chose to only use the LVar momentarily, this won't work. You will have to try, there is no knowing this in advance. You would create a script like this and save it. (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (SPEAK:on) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }Then use Scripting->Aircraft automated Scripts to run it every 500ms or something. Then, every time you turn on the battery (or rather, flip the switch to "on"), your computer will say "on" - that's what the SPEAK command does. Replace the SPEAK command with whatever you need, probably EXECBAT - see AAO manual. Be mindful that this is just off the top of my head. None of this is tried or tested.

What do you mean by "convert"? In general I would expect that you can just use the Lorby StreamDeck editor to drag the actions from the StreamDeck profiles to the StreamDock ones (you don't need an actual Elgato StreamDeck to install their software and consequently their profiles). But it has been a long time since I tried this myself. Neither the StreamDeck nor the Mirabox plugins were meant as actual features of AxisAndOhs. They are just examples of what to use AAO's WebAPI for and how to do it. They are a bit of Javascript, demonstrating the communication between the device software and the AAO API. The plugins are not set in stone, feel free to adapt and alter them at your leisure.

It does work for me, using the "StreamDock" software that comes with the original Mirabox N4. Version number is 3.10.194.0707, no further updates are available. The devices of the various brands and their associated software can be slightly different. As the AAO plugin is just a bit of Javascript, feel free to correct/alter it to your needs. The UI software should have a debug mode or debug web page, with the Mirabox it is http://localhost:23519/ But you may have to activate debugging first, not sure.

App focus issues are usually only relevant when you are using keyboard commands? In any case, I would not start AAO with the sim, that would be the first step. Next, disable Mobiflight and Voice Attack, see what happens. (are you aware that AAO also does voice recognition?) Mobiflight in particular can be problematic when used with AAO. Both apps essentially do the same thing(s), and they can step on each other's toes. P.s.: I won't be looking at your screenshot, sorry. My AntiVirus flags that web page as malicious.

In AAO you use the (EXECBAT: command, see AAO manual around page 83 "AAO specific RPN commands". But "click on a switch in the cockpit" can have many different consequences, and only very few of them can be observed from the outside by AAO. Essentially the sim only "reports" K: events and IEs over SimConnect. For those you can use the (LISTEN_FOR_RPN or (LISTEN_FOR_K script headers to catch whatever is being sent from your switch. If the switch doesn't send anything that you can observe, that would mean that you have to alter the switches' code in the sim to make that happen. Are you the developer of the aircraft? Ideally you would add a bit of Javascript to access the AAO WebAPI and send the EXECBAT command directly.

Then I have to assume that the issue is specific to your computer. Not sure how I can help with that. I don't even know where to start looking, this has not been observed before. If I have to guess, I would say that a piece of software, another addon or a driver is interfering here. Also, when there are app focus isues, I wouldn't let the sim start AAO. I always do it the other way round, my AAO starts the sim. That also prevents problems with admin privileges.

The correct syntax would be (L:1:CONST_FEATHER_Switch1, Number) LVars that are to be synchronized with the sim must have a unit in AAO. Use "Number" when in doubt. Otherwise the LVar remains internal to AAO (so you can freely use your own LVars in your scripts without weighing down the interface to the sim). On a side note, in the latest SDK documentation for MSFS 2024 Asobo says that "L:1:" equals "Z:". Don't know if that is true though.

Sorry, but no, no idea. To me this looks like SimConnect has just been terminated from the other side - which is probably exactly what happened when the sim crashed. This does not tell you anything about the cause. I doubt that an AAO logfile can be of much use here anyway (because it is the sim that has problems, not AAO!). Only if there were hundreds or even thousands of exceptions in the file, that would be an indication that you did something wrong with your assignments. Unfortunately that is all theory, there is no viable way to nail this down in a deterministic way. I still stand by what I wrote earlier. Something in your sim or in your computer does not agree with either AAO itself, its Community packages, or the .Net framework in general. That is entirely possible, which is why there is a DEMO version of AAO that everybody should try before purchase. Just look at my own devel computer - it just does not like MSFS. No matter what I tried, I never found out why that is.

What does that mean? You don't need the Community packages in normal operations, AAO works just the same without them. They have a special purpose that you probably won't need anyway.