search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
37 stars 8 forks source link

[Bug]: Can't activate Frutto LED panel from Web UI interface #342

Closed JMills75 closed 2 weeks ago

JMills75 commented 2 weeks ago

What actions were attempted?

I attempted to enable the Frutto LED panel from the ESP32 web UI.

What actually happened?

When I clicked update Settings, I got a visual prompt but no sound. I could not save it to EEPROM. I could no longer start my pack using the ion arm power switch. I recycled the power, and everything came back to normal.

I was able to update the setting in the LED EEPROM Level 2, setting 2

What was expected?

I expected to succsessfully enable the panel in the WebUI with the normal sound prompts.

Firmware Version

5.3.1

Mode in Use

Super Hero / Video Game

Notable Hardware

Frutto Inner Cyclotron LED panel. 36 LED pixel inner cyclotron ring.

Homework Completed

JMills75 commented 2 weeks ago

After looking at Dustin's video it looks to be expected behavior (the lights). Please ignore that question.

nomakewan commented 2 weeks ago

Checking the code to see if anything jumps out at me, nothing did. The configuration packet definitions match between the Attenuator and Pack, the Attenuator Web UI sets the proper variable which is then set to the proper variable in the configuration packet, and the pack correctly unpacks this into the b_inner_cyclotron_led_panel boolean variable.

That your pack completely stopped responding I think is the key clue here. I'm going to tag in Dustin since this is Attenuator-related, but I'm guessing system stability may come into play.

DustinGrau commented 2 weeks ago

If there are different colored lights, then this is working. It may not have seemed like it was enabled due to feedback prompts, but the lone green light says it's good. If they were all the same color and moving in sequence then it would have been because the pack thought those addressable LEDs were part of the inner cyclotron.

DustinGrau commented 2 weeks ago

I'm confused by what was meant by this: "My pack did not power down but stopped responding to the ion arm power switch."

JMills75 commented 2 weeks ago

I didn't state correctly, becaue you can't change settings when the pack Is running. I couldn't start the pack using the ion arm switchbafter attempting to xhange the setting. The switch stopped responding. I'll try to qreproduce the problem again.

JMills75 commented 2 weeks ago
  1. I disabled the panel in the UI successfully
  2. I power-cycled the pack
  3. connected to the UI, and attempted to enable the panel
  4. I could not save the settings
  5. I could not start the pack.
  6. I've attached a video of my pack not responding after the save attempt.

https://github.com/gpstar81/GPStar-proton-pack/assets/16563067/429acb4e-9a18-48a1-b144-0077121dc63f

DustinGrau commented 2 weeks ago

The video seems to be capped at 1 second--was this intentional or was there an issue with uploading if the original is longer? Can you start the pack after power-cycling? The general rule is that anything which would require an EEPROM change should ideally require a full power-off at the battery. This means anything which changes the lights and hardware configurations.

JMills75 commented 2 weeks ago

Yep, I capped the video due to the file size limitations of Github. I can start the pack after a power cycle but the panel is not enabled

DustinGrau commented 2 weeks ago

I'm really confused. I thought you had the panel working?

Go into the UI or EEPROM menu, enable the panel, save, and power-cycle the equipment. Does it work?

JMills75 commented 2 weeks ago

I can enable the panel through the EEPROM, the issue occurs when I try to enable the panel through the UI. There are no issues making changes through the EEPROM menu.

DustinGrau commented 2 weeks ago

That's incredibly odd as I only enabled my own panel through the UI, and it's only job is to change 1 value to "true".

JMills75 commented 2 weeks ago

I will try a few steps to trouble shoot and come up with additional details.. I appreciate the help digging into it!

DustinGrau commented 2 weeks ago

The logic that sets/gets and otherwise deals with this boolean value is EXACTLY the same as every other field in that UI screen. I am at a loss as to why this would be any different in behavior from the other toggles on the pack equipment screen. The data coming across is the same datatype, gathered in the same way, and set the same way. For all intents and purposes this should work without ANY issue, and in fact was the only way I tested the initial changes. So as to why it doesn't behave for you is baffling.

Just use the EEPROM and call it a day. If someone else has the same issue we'll deal with it with fresh data unless there's something truly missing from your steps. I'd ask you to use a computer and look at the network data on your browser to see the JSON data being sent--but I'm guessing that's going to be met with some confusion.

JMills75 commented 2 weeks ago

That is completely fair. I don't plan to turn it off again in the future.

I'm familiar with getting information from the Dev console in Chrome. I can pull JSON if necessary. I will give that a shot tomorrow.

DustinGrau commented 2 weeks ago

FML, it's not this action per se, as disabling the panel works almost immediately. Enabling the panel also works, but doesn't trigger the sound feedback as something must be going wrong with the update of values on the pack. Eventually my save attempts corrupted the EEPROM data and it got completely reset. Something must be mis-calculated or invalid when saving the data which causes the code to not reach the sound effect portion to indicate the save happened.

DustinGrau commented 2 weeks ago

Found it, order of operations after updating the flag on the pack. The logic to get the new start/end sequence for the devices came BEFORE setting of the # of LEDs on the panel device. This caused a mis-calculation which was in disagreement with the state of the panel and caused an unseen error. The change is now instantaneous but should still be committed to EEPROM and power-cycled as a matter or practice.

DustinGrau commented 2 weeks ago

Will be available in the 5.3.2 release when that is ready