Spirit LUA did not show/modify data any more since Ethos 1.5.8

[joy2417]

With Ethos 1.5.8 and 1.5.9 the Spirit LUA did not work any more. The script is starting and the Spirit goes to config mode (blue LED slow binking) but it is not able to read any config from Spirit and show it in the menus. If you leave the Script you are back in flight mode.

[bsongis-frsky]

No error?

[joy2417]

There is no error message. You can dive into the submenus but there are no values in the fields and so you can't change anything. I informed the Spirit developers in the Spirit forum too. https://www.spirit-system.com/phpBB3/viewtopic.php?f=20&t=5501&start=230 Maybe you can get in contact with them yourself. This is much better than my "Chinese Whispers".

[dehigama]

@bsongis-frsky downgrading to Ethos ver1.5.7 - ver 1.5.6 works. I have downgraded to ver1.5.6 the Spirits integration works but I see large amount of padding at the top, therefor the need to scroll down the page to get to the first parameter values. this is at least for me minor issue than its completely not working from Ethos ver1.5.8.

thank you

[joy2417]

@dehigama but the scroll down problem was gone in 1.5.7 This was the last version the Spirit script was working.

[bsongis-frsky]

I am not sure that the Lua is open source, so it will be difficult to help here. Unless it's already fixed in the latest nightlies?

[azaz44]

Script is unfortunately closed source. Errors are these:

<27>[31m061773 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062058 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062104 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062329 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062377 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062636 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062686 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062918 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m062967 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
Event received:<9>0<9>97<9>0<9>0<9>35<\r>
<27>[31m063204 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>
<27>[31m063254 wakeup() error: ?:-1: attempt to index a userdata value (field '?')<27>[0m<\r>

[joy2417]

Unless it's already fixed in the latest nightlies?

For testing I need X14S EU version

[robthomson]

This will need spirit to look at it. End of day.. they have the source and can debug their code. Maybe you can ask them to drop past this thread?

[azaz44]

This will need spirit to look at it. End of day.. they have the source and can debug their code. Maybe you can ask them to drop past this thread?

Script was working in previous Ethos versions.

[robthomson]

But there is zero way for Frsky to debug this when the spirit lua is compiled and they have no spirit fbl.

So all up.. Spirit will need to be made aware and issue a fix / fault report with some proper debug.

[bsongis]

When I find an error in the compiler, I have to give some evidence (i.e. the code which produces the error). Not just say that it worked before and now it is broken!

[joy2417]

Tomas from Spirit knows about this issue: https://www.spirit-system.com/phpBB3/viewtopic.php?f=20&t=6097&start=20

[azaz44]

But there is zero way for Frsky to debug this when the spirit lua is compiled and they have no spirit fbl.

So all up.. Spirit will need to be made aware and issue a fix / fault report with some proper debug.

I think it is very unfortunate that Spirit scripts are closed source. I don't understand this decision at all.

But at the same time, I try to see both sides of the story. If script doesn't work anymore in next Ethos version, then even if we don't know why, we can assume that it is 80 percent chance something got broken in Ethos. Lua API is meant to be backards compatible, otherwise you can forget people writing and publishing any scripts at all. So it is not great to break things in LUA handling in Ethos and tell script authors they now need to retest everyhing or redevelop stuff.

I think it just needs a more polite approach. If issue is really in Ethos (and yes, we don't know at this point, it's just most likely), then it is actually equally in Ethos team interest to fix it as it is in Spirit team, isn't it?

[BladeScraper-Designs]

I agree - Rotorflight/Betaflight, even FrSky themselves' own Luas for SRx and RBx units are raw source code that anyone can view, edit, improve, fix, etc.

If a manufacturer (e.g. Spirit, Brain) decides they want to only distribute compiled Luas for their integration, that forces all responsibility to maintain the Lua solely to them, and even FrSky cannot help with debugging/fixing unless the manufacturer shares their source code. FrSky are very open and willing to help, and if you take a look at the Rotorflight Lua, you can see the effects of such. Even Ethos itself has been updated in recent 1.5 updates to include features relevant to integrations.

Spirit Lua is broken in latest versions of 1.5, but the Brain Lua works fine on the latest. In most cases, when a Lua breaks in an Ethos update, it is Ethos' fault (though sometimes a poorly done function that happens to work in a previous Ethos version may break in a newer Ethos version) - but again, it comes down to the manufacturer to fix it if FrSky is unable to test and debug with the raw source code.

There is always a nightly firmware put out, before it is published as a new Ethos Release. Manufacturers and otherwise developers of 3rd party Luas are supposed to use these nightlies to test and find issues, whether they are Lua or Ethos as the cause. If a fix cannot be found by rewriting parts of the Lua, then it must be Ethos - and such situations should be reported to FrSky so they can investigate. So far, Spirit has not done so.

[robthomson]

End of the day.. There can, never be a garuantee of lua scripts working in future versions.

Hell.. Even Microsoft don't garuantee this with Windows.

Software is typically released with a compatability notification.. And manufacturers then test and update their scripts and code when new versions are released.

For sure this is how I am doing the rotorflight luas. It's pretty easy to feature flag based on os version and then operate on a different way.

[azaz44]

Yeah guys, sounds great, but what does it mean for us, users? It doesn't help at all. We just have no integration.

With Spirit we (users) have a lot of problems since we use Ethos. Scripts were stable for OpenTX, but for Ethos thety don't support everything yet. Log viewer is not there yet, and integration scripts have some issues. Very unfortunate I have to say. But at the same time I try to understand, that Ethos in helis makes for something below 1 percent of the market. Developing these luas is lots of work, as they work on many things at the same time. Thinking that Ethos is the only thing in the world and they will jump on fresh nightlies to retest their scripts every day is just miles away from any reality. I rather think it's quite an investment for them, to get back to LUA development for Ethos and fix issues in scripts they developed once and hoped they will work forever or long time at least. And at the same time, Spirit scripts were developed and working in 1.4.x, then they didn't work anymore in early 1.5, then they were workng again in later 1.5, and now they don't work again. How likely would you come back to this investment if you would run Spirit? They would rather wait until the API in Ethos, which makes for this 1 percent, gets stable, this is obvious.

Yes there's not much Ethos team can do with a closed source script, I agree with that. But just making it checked 'spirit issue, problem solved' doesn't sound right to me.

[azaz44]

End of the day.. There can, never be a garuantee of lua scripts working in future versions.

Sorry but this is just so wrong, I hope Ethos team nver thinks this way. Otherwise it's a message to everybody 'don't bother writing luas for this'.

[BladeScraper-Designs]

They choose to support the OS with their systems. It's their responsibility to ensure it stays that way. That is how it works, has always worked, will always work. Same way someone who writes software for Linux has to ensure their software works with the latest Kernel. Even if the issue comes down to a change in the Kernel, it is their responsibility to report the issue to the devs so it can be fixed (if it is indeed a bug in the kernel and not in the software). I really don't get why such a basic concept is so hard to understand when any other industry understands it fine. Plenty of 3rd party Luas out there for Ethos that manage to maintain their scripts with the occasional change to the OS/Lua interpreter.

[robthomson]

No.. This is called software development.

Release a Linux app for ubuntu 10.. Garuantee it won't work on Ubuntu 11 without a recompile.

It's not hard to write software in lua to check the version on startup and say it is not going to work.

This is exactly how rf lua does it.

If you try use the script on an unsupported version it will simply not run.. But alert you.

[azaz44]

They choose to support the OS with their systems. It's their responsibility to ensure it stays that way. That is how it works. Same way someone who writes software for Linux has to ensure their software works with the latest Kernel. Even if the issue comes down to a change in the Kernel, it is their responsibility to report the issue to the devs so it can be fixed (if it is indeed a bug in the kernel and not in the software). I really don't get why this basic concept is so hard to understand when any other industry understands it fine. Plenty of 3rd party Luas out there for Ethos that manage to maintain their scripts with the occasional change to the OS/Lua interpreter.

Hmm, do you really imagine linux kernel team breaking public API which Is meant to be stable and used by others, and then claiming 'this is not our problem unless you file an issue with details'... ?

[BladeScraper-Designs]

It happens, yes. And?

If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens. And that's just the Debian core - which is realistically more comparable to the Ethos situation than the Kernel.

Ethos will stabilize over time. Right now lots of things are being updated, added etc to improve functionality in the Lua department, possibly at the expense of breaking functionality in some Luas (and if no one tells them they made an issue, they will persist). Some Lua writers are taking advantage of it, improving the functionality, interface, etc of the integration they provide to their customers... others are not.

[azaz44]

No.. This is called software development.

Release a Linux app for ubuntu 10.. Garuantee it won't work on Ubuntu 11 without a recompile.

It's not hard to write software in lua to check the version on startup and say it is not going to work.

This is exactly how rf lua does it.

If you try use the script on an unsupported version it will simply not run.. But alert you.

Sorry but what you write is just phantasy 🙂

[azaz44]

It happens, yes. And?

If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens.

But it doesn't mean it should.

BTW guys, if it is by any means RF promotion, I'm all in to an open source fbl and would love to try RF. I just miss some of features there, but would probably try RF in my next heli. But I see benefit of having different systems and competition. There's nothing better for ususers, even if some of them feel safer having only one option. I don't think fights are needed in a small market, which (luckily) slowly grows.

[bsongis]

@azaz44 Rob is right. Do you need more examples? Python2 to Python3. Or even something more recent ... Angular?

All software evolve. We are humans and the interfaces we setup are perfectible. We are forced to mark some old API as deprecated. And then in a next version your script won't work, because it will call functions which have been removed.

[azaz44]

It happens, yes. And? If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens.

But it doesn't mean it should.

BTW, what I meant with whay you probably refer to 'it happens' is not software being broken in next update, but rather linux kernel team being happy with that.

[azaz44]

@azaz44 Rob is right. Do you need more examples? Python2 to Python3. Or even something more recent ... Angular?

All software evolve. We are humans and the interfaces we setup are perfectible. We are forced to mark some old API as deprecated. And then in a next version your script won't work, because it will call functions which have been removed.

I agree with that.

But, was there any API becoming deprecated in this Ethos vesion? API change? Sth removed? Or was sth broken unintentionally and we don't even know what?

(And I understand that we don't really know breaks the script at this point. We just know Ethos is newer and script same,)

[BladeScraper-Designs]

It happens, yes. And? If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens.

But it doesn't mean it should.

BTW guys, if it is by any means RF promotion, I'm all in to an open source fbl and would love to try RF. I just miss some of features there, but would probably try RF in my next heli. But I see benefit of having different systems and competition. There's nothing better for ususers, even if some of them feel safer having only one option. I don't think fights are needed in a small market, which (luckily) slowly grows.

Of course, it "shouldn't". But it happens, and generally it is unavoidable. This hobby is small, and the dev team for a given project is only so big. It needs to be a whole collaborative effort between all parties - 1st, 2nd, and 3rd - to ensure all customers for all parties are satisfied.

It happens, yes. And? If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens.

But it doesn't mean it should.

BTW, what I meant with whay you probably refer to 'it happens' is not software being broken in next update, but rather linux kernel team being happy with that.

I would not say the Ethos team is happy with it. But until the issues are presented, how can they even know they exist so they can fix it?

[azaz44]

It happens, yes. And? If only you knew the train of updates I had to put my 3D printer through because I updated from Buster to Bullseye. ALL of my software broke. It happens.

But it doesn't mean it should. BTW guys, if it is by any means RF promotion, I'm all in to an open source fbl and would love to try RF. I just miss some of features there, but would probably try RF in my next heli. But I see benefit of having different systems and competition. There's nothing better for ususers, even if some of them feel safer having only one option. I don't think fights are needed in a small market, which (luckily) slowly grows.

Of course, it "shouldn't". But it happens, and generally it is unavoidable. This hobby is small, and the dev team for a given project is only so big. It needs to be a whole collaborative effort between all parties - 1st, 2nd, and 3rd - to ensure all customers for all parties are satisfied.

I fully agree with that, 100 percent.

[robthomson]

🙂

No.. This is called software development. Release a Linux app for ubuntu 10.. Garuantee it won't work on Ubuntu 11 without a recompile. It's not hard to write software in lua to check the version on startup and say it is not going to work. This is exactly how rf lua does it. If you try use the script on an unsupported version it will simply not run.. But alert you.

Sorry but what you write is just phantasy 🙂

Right. So it's fantasy that software functions do not change / become deprecated over time.

It's fantasy that systems evolve and change.

Its fantasy that my php code I wrote 2 years ago does not work on newer php installs.

It's fantasy that WordPress for example constantly updates and forces php version upgrades to keep compatability.

Do I continue or do you you want to continue showing your ignorance of software development?

We all get that you have an issue. And yes.. You want it to work.

Question.. Did you backup your radio first so you could roll back If you had an issue?

Lua is going through major updates which are making the capability of the system so much better and more functional for developers. It is inevitable that occasionally scripts will have unexpected issues.

It's not however possible to just solve these when the script is compiled and there is no ability to debug it.

I suggest that you log an issue with spirit. It's currently in their hands to debug and find out why as there is no possible way from this end. I can garuantee that frsky will help resolve the issue with them if they can provide some debug.

If they are going to take months to do this.. Well.. Painfully yes but your only option at that point will be to downgrade and wait.. Or use a more responsive manufacturer who is keeping abrest of the updates and preparing for a new release version.

[azaz44]

I would not say the Ethos team is happy with it. But until the issues are presented, how can they even know they exist so they can fix it?

Issue is there reported by users. And it's unknown what happens, but with my exp in software development I would probaly estimate 80 percent breaking change in Ethos (20 percent script badly written which caused a failure in next Ethos version), 60 percent it will affect other LUA scripts too.

There's not enough data to resolve the issue (worst kind of issues to solve) but just some kind of 'being open' will be very useful. I could for example try to run the scripts and see where it fails (I decompiled them once), although it might help little. It would of course be best if Spirit would help, but I wonder how likely it is considering reality which I outlined earlier.

One thing I could surely do is to capture all APIs thet use in their script. Their script has no chance of hiding that.

[robthomson]

It would be much simpler if spirit could get in touch on a git request to link to with the right people.. Hell.. Get them to contact me and I can get them in touch.

I don't see any chance of solving this without their input. Likely it could be fixed within 12 hours if they did. But with no ability to know what they are doing... Well.. That could take weeks of guessing.

[azaz44]

🙂

No.. This is called software development. Release a Linux app for ubuntu 10.. Garuantee it won't work on Ubuntu 11 without a recompile. It's not hard to write software in lua to check the version on startup and say it is not going to work. This is exactly how rf lua does it. If you try use the script on an unsupported version it will simply not run.. But alert you.

Sorry but what you write is just phantasy 🙂

Right. So it's fantasy that software functions do not change / become deprecated over time.

It's fantasy that systems evolve and change.

Its fantasy that my php code I wrote 2 years ago does not work on newer php installs.

It's fantasy that WordPress for example constantly updates and forces php version upgrades to keep compatability.

Do I continue or do you you want to continue showing your ignorance of software development?

We all get that you have an issue. And yes.. You want it to work.

Question.. Did you backup your radio first so you could roll back If you had an issue?

Lua is going through major updates which are making the capability of the system so much better and more functional for developers. It is inevitable that occasionally scripts will have unexpected issues.

It's not however possible to just solve these when the script is compiled and there is no ability to debug it.

I suggest that you log an issue with spirit. It's currently in their hands to debug and find out why as there is no possible way from this end. I can garuantee that frsky will help resolve the issue with them if they can provide some debug.

If they are going to take months to do this.. Well.. Painfully yes but your only option at that point will be to downgrade and wait.. Or use a more responsive manufacturer who is keeping abrest of the updates and preparing for a new release version.

Let me address some of these.

First of all I'm not original poster. I have the same probem too, but I learned to live without integration for 2nd season now. I get away with this, although it's a major downgrade for me after moving to Ethos from OpenTX. And I value Ethos so much that I choose hardware for me so it has Ethos.

Then, we're talking about public API which people and companies (like Spirit) are developing against. And yes, APIs do get breaking changes when it's unavoidable, but are kept stable otherwise. And it makes a big difference, if there was such a breaking change in new Ethos version, which is known and announced (nothing is there in release notes), or if something got broken unintentionally as a bug. Introducing a breaking change because of a bug and saying 'it's fine' is what I try to vote against. I don't say Ethos team does it, nothing like that, you try to convince me this is great. I think it isn't.

And besides that, also for @bsongis-frsky I perfectly understand that with helis we are a niche. For Spirit FBL, 'Ethos' is a very minor part of the whole thing. And for Ethos + FrSky heli market is not huge, and heli+spirit market is even smaller. So we, users of Spirit and Ethos are in an unfortunate situation. Kind of, we have to be happy that there is any support for helis in Ethos, and that there is any support for Ethos in Spirit. But some of us think Ethos is one of if not the best OS for a radio out there and promote it for helis, hopefully nothing wrong with that.

So I hate to see Ethos guys thinking 'helis are small, let them report details then we maybe fix sth' and Spirit guys thinking 'one percent of our users use Ethos, and they broke it in version x, then fixed in y, then broke in z, let's just wait until they get mature and stable'. Then all win except of us users.

[azaz44]

It would be much simpler if spirit could get in touch on a git request to link to with the right people.. Hell.. Get them to contact me and I can get them in touch.

I don't see any chance of solving this without their input. Likely it could be fixed within 12 hours if they did. But with no ability to know what they are doing... Well.. That could take weeks of guessing.

Are you in Ethos team?

[robthomson]

So I think your view that frrsky think helis are niche and small is incorrect.

Frsky have worked hard with me for a few months now to get rotorflight support working well. And all up that's quite niche.

The issue here is that frsky cannot be expected to fix a problem that they do not have the source code for - and the developers of the product have not to my knowledge reached out to frsky to try solve.

No matter how much you bang on about it.. The situation does not change. Spirit / spirit devs will need to get in touch. It's also not frsky job to chase after a third party coder to solve an issue with their script

So.. If you want this so bad reach out to spirit and ask them to look into it and get in touch.

If they are not bothered to look into it - well.. Not sure how to go forward on that.

In terms of ethos team.. I am a third party. But I have worked with frsky since the earliest days of opentx. I like to think that i have a good relationship and friendship with some instrumental members of their company. I have known them a very long time!

So.. In summary.

Spirit need to get in touch. Not sure how else this will be solved. I have zero relationship with them. Maybe you do? If so.. Reach out as a customer. Point them here and get some usefull and constructive dialog going. The current range of posts on this topic are serving no purpose on git and would best be keep to forums or Facebook.

[azaz44]

So I think your view that frrsky think helis are niche and small is incorrect.

Frsky have worked hard with me for a few months now to get rotorflight support working well. And all up that's quite niche.

The issue here is that frsky cannot be expected to fix a problem that they do not have the source code for - and the developers of the product have not to my knowledge reached out to frsky to try solve.

No matter how much you bang on about it.. The situation does not change. Spirit / spirit devs will need to get in touch. It's also not frsky job to chase after a third party coder to solve an issue with their script

So.. If you want this so bad reach out to spirit and ask them to look into it and get in touch.

If they are not bothered to look into it - well.. Not sure how to go forward on that.

In terms of ethos team.. I am a third party. But I have worked with frsky since the earliest days of opentx. I like to think that i have a good relationship and friendship with some instrumental members of their company. I have known them a very long time!

So.. In summary.

Spirit need to get in touch. Not sure how else this will be solved. I have zero relationship with them. Maybe you do? If so.. Reach out as a customer. Point them here and get some usefull and constructive dialog going. The current range of posts on this topic are serving no purpose on git and would best be keep to forums or Facebook.

Sorry but I feel like you weren't reading anything :( If it's a bug in Ethos, then it's not only Spirit script which has a problem now, I wonder why this is so hard to understand. Also wondering what's the point of banging other user requests if you're not in dev team, not using Spirit, not having anything to do with this script... But whatever, I think better spent time on productive things as everything was already said in this discussion.

[azaz44]

@bsongis I made some debugging. Spirit script is not only compiled but obfuscated too, which makes this tricky. But what I was able to find out

• script fails, when trying to get enable field from Choice object
• enable is a function, but it fails not when invoking it, but just getting it from the object
• in 1.5.6 this works all the time. In 1.5.8 this fails, but I think randomly, not always (not 100% sure on that).
• the error is:

  040102 wakeup() error: SD:/scripts/spirit2/main.lua:2687: attempt to index a userdata value (local 'L4_2')

• when this happens, L4_2 is a Choice object, and script just does L4_2 = L4_2.enable (to later make a call on L4_2 which is then a function). This line fails.

Does this put any light? I checked changes in 1.4.8 and there is plenty of LUA, but nothing about Choice,

[robthomson]

So I think your view that frrsky think helis are niche and small is incorrect. Frsky have worked hard with me for a few months now to get rotorflight support working well. And all up that's quite niche. The issue here is that frsky cannot be expected to fix a problem that they do not have the source code for - and the developers of the product have not to my knowledge reached out to frsky to try solve. No matter how much you bang on about it.. The situation does not change. Spirit / spirit devs will need to get in touch. It's also not frsky job to chase after a third party coder to solve an issue with their script So.. If you want this so bad reach out to spirit and ask them to look into it and get in touch. If they are not bothered to look into it - well.. Not sure how to go forward on that. In terms of ethos team.. I am a third party. But I have worked with frsky since the earliest days of opentx. I like to think that i have a good relationship and friendship with some instrumental members of their company. I have known them a very long time! So.. In summary. Spirit need to get in touch. Not sure how else this will be solved. I have zero relationship with them. Maybe you do? If so.. Reach out as a customer. Point them here and get some usefull and constructive dialog going. The current range of posts on this topic are serving no purpose on git and would best be keep to forums or Facebook.

Sorry but I feel like you weren't reading anything :( If it's a bug in Ethos, then it's not only Spirit script which has a problem now, I wonder why this is so hard to understand. Also wondering what's the point of banging other user requests if you're not in dev team, not using Spirit, not having anything to do with this script... But whatever, I think better spent time on productive things as everything was already said in this discussion.

I think you are so focused on this being a bug in ethos that you are not realising it could be a simple fact of their script using a deprecated function.

Now.. To my understanding spirit are aware and already working on a fix and new release.

Best you take up further discussion with them as any debug work you do seems a bit pointless if they are already planning a revised release.

[azaz44]

I think you are so focused on this being a bug in ethos that you are not realising it could be a simple fact of their script using a deprecated function.

Yes. Because there are no functions which got deprecated in 1.4.8 compaing to 1.4.6. We have release notes, luadoc etc.

[azaz44]

I also tested on today nightlies, it doesn't work, behaves same like 1.4.8.

[joy2417]

Tomas from Spirit System has solved the problem with the changed LUA system. https://www.spirit-system.com/phpBB3/viewtopic.php?f=20&t=6097&start=25

I will test it as fast as possible if the script is published and there is a X14S_EU 1.5.10 nightly.