• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login

Replacing Mausberry Script with a Python script

Scheduled Pinned Locked Moved Ideas and Development
shutdown scriptshutdown switchmausberry
33 Posts 6 Posters 7.9k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    caver01 @cyperghost
    last edited by 18 Sept 2017, 18:16

    @cyperghost Yes. I may work on this a little bit today. It's great to collaborate! Thanks for your help!

    My 4-player cocktail style cabinet built as a custom "roadcase"

    C 1 Reply Last reply 19 Sept 2017, 21:46 Reply Quote 1
    • C
      cyperghost @caver01
      last edited by 19 Sept 2017, 21:46

      @caver01 Here is an very intersting thread https://retropie.org.uk/forum/topic/12930

      1 Reply Last reply Reply Quote 0
      • D
        DIY_glenn
        last edited by 28 Sept 2017, 13:08

        This is great!

        I'm just finishing up my Mausberry mod to fit a NESPi case. The reset switch has been removed. For those who doesn't know, it is a function of the Atmel Tiny25 chip, you just reset the chip directly, effectively risking corrupting the card, which is why I won't use it.

        But I've connected the Reset button on my NESPi to GPIO instead, so it can be used for something more useful. F.ex. one click = reset ROM, double click = reboot etc.

        Excellent to see the script being transferred to Python rather than BASH, I'm a super-newbie with Python, but interrupts vs polling is why I started searching for something else than the Mausberry script. Also the possibilities of Python in general, to be able to use the script for more functions.

        C L 2 Replies Last reply 28 Sept 2017, 16:26 Reply Quote 0
        • C
          caver01 @DIY_glenn
          last edited by 28 Sept 2017, 16:26

          @diy_glenn There have been a few developments for me regarding this idea. Aside from the excellent work that was done to make the original BASH script more robust for RetroPie (meaning, it is capable of safely exiting emulators and Emulation Station to save metadata), recent developments in this thread allows us to revert to a simpler version and removes the need to reproduce the new BASH script in python.

          What @meleu has built in that thread is basically a service that does nothing while running but stays resident so that upon shutdown (any shutdown) it triggers a script that gracefully exits emulators and ES. He's taken the customization out of the hands of a mausberry script (or any shutdown solution for that matter) whether you are using BASH or python. It no longer matters because his service and its accompanying killes.sh script handles the graceful closure automatically.

          Once setup (and crucially, once you chmod the killes.sh as executable) the original mausberry script can be used. Moreover, we can switch to the python script I shared in the original post above and still enjoy the benefits of graceful exit of ES.

          One tiny fly in the ointment is that the mausberry circuit seems to be blind to software-initiated shutdowns. While this allows reboots to occur unhindered, it is inconvenient when a user selects QUIT>SHUTDOWN from the UI. The circuit does not start watching its GPIO for power drop until AFTER it detects a button push.

          My workaround for this is to add a "trigger" command to @meleu's killes.sh which "presses" the mausberry switch! Basically, I am exporting a GPIO pin and raising the value to 1. Attached to the pin, I have a 1k-ohm resistor, then the base of an NPN transistor. The collector and emitter of the transistor are connected to the mausberry switch poles (in parallel with the actual switch). SO. . . when the GPIO goes HIGH, that triggers the transistor to short the switch poles (like pressing the button). This in turn gets the mausberry circuit to start watching its own GPIO input to go LOW (because the Pi is shutting down). When it sees the Pi is down, it cuts power.

          The fallout, for now, is that I cannot differentiate between a shutdown and a software reboot. In either case, the killes service ends, the script executes, and my transistor presses the button. That means REBOOT always results in POWEROFF. I am OK with that right now.

          My 4-player cocktail style cabinet built as a custom "roadcase"

          C 1 Reply Last reply 28 Sept 2017, 16:58 Reply Quote 1
          • C
            cyperghost @caver01
            last edited by 28 Sept 2017, 16:58

            @caver01 Yes you can ;)
            I'm getting in touch with that .... and I hope @meleu will pump up the code a bit.
            I'm posting in a new topic ;)

            1 Reply Last reply Reply Quote 1
            • C
              caver01
              last edited by 28 Sept 2017, 17:25

              One other development for me is that I am running a couple of GPIO-connected pushbuttons on my cabinet already. I use these to trigger volume commands handled by yet another python script. I am using GPIOneer, but I will soon be switching to its replacement software, GPIOnext. This is a great little driver for arcade control input, and even though I have an IPAC, it is very handy to trigger commands, not just keystrokes.

              With the killes service working, my plan is to drop the use of a mausberry script completely and shift the responsibility over to GPIOnext. A clever observation by the developer revealed that there is no need to script the input for the Mausberry circuit. The script sets up a pin to be monitored, but you could just as easily connect the IN lead to the 3.3v rail (GPIO header pins 1, or 17 for example). When the Pi shuts down, that rail will drop, and the mausberry circuit (if paying attention after a button press) will see that the Pi has shutdown.

              The other half of the mausberry script is trivial. You can simply define a shutdown command in GPIOnext triggered by the GPIO you connect to the OUT lead the mausberry circuit.

              My 4-player cocktail style cabinet built as a custom "roadcase"

              M 1 Reply Last reply 28 Sept 2017, 20:24 Reply Quote 0
              • M
                meleu @caver01
                last edited by 28 Sept 2017, 20:24

                @caver01 Please, tell me what would be the commands you want to execute at shutdown and the commands you want to execute at reboot (that echo "$GPIOpin" > /sys/class/gpio/export stuff).

                [BTW, I'm getting crazy with we discussing the same issue in several different threads! :-) ]

                • Useful topics
                • joystick-selection tool
                • rpie-art tool
                • achievements I made
                C C 2 Replies Last reply 28 Sept 2017, 20:46 Reply Quote 0
                • C
                  caver01 @meleu
                  last edited by 28 Sept 2017, 20:46

                  @meleu said in Replacing Mausberry Script with a Python script:

                  [BTW, I'm getting crazy with we discussing the same issue in several different threads! :-) ]

                  I am with ya. Just trying to respect the original posts in most cases. Anyway. . .

                  Please, tell me what would be the commands you want to execute at shutdown and the commands you want to execute at reboot (that echo "$GPIOpin" > /sys/class/gpio/export stuff).

                  This is what has to be executed to trigger the transistor for a soft shutdown:

                  echo 18 > /sys/class/gpio/export
                  echo "out" > /sys/class/gpio/gpio18/direction
                  echo "1" > /sys/class/gpio/gpio18/value
                  

                  The first two lines can be invoked at startup (which I do). They are necessary because you have to export the pin and set its direction before you can write a value to it. The third line can be placed in a different script and must wait until the moment a shutdown is requested.

                  For a reboot, NONE. No additional code needed (nor wanted), as you want the circuit to continue to deliver power during a reboot.

                  My 4-player cocktail style cabinet built as a custom "roadcase"

                  C 1 Reply Last reply 28 Sept 2017, 20:49 Reply Quote 1
                  • C
                    caver01 @caver01
                    last edited by caver01 28 Sept 2017, 20:49

                    I also abstracted the Pin# in my actual code with stuff like:

                    GPIOpin=18then replacing "18" in the code above with $GPIOpin. You get the idea. It just makes it easier to change 18 in one place at the beginning of the script than in multiple commands.

                    My 4-player cocktail style cabinet built as a custom "roadcase"

                    1 Reply Last reply Reply Quote 1
                    • C
                      cyperghost @meleu
                      last edited by 29 Sept 2017, 14:19

                      @meleu @caver01

                      [BTW, I'm getting crazy with we discussing the same issue in several different threads! :-) ]

                      Haha.... well what about annother thread named: "A good solution is really good if two idiots got the same idea" ;)

                      @meleu I think we can solve this and got a really good solution. I think that compining the incron method + system.d is a good working team. But then the killes-code has to be a bit modified. I can take this approach.

                      But I need you @caver01 as test candidate as I still don't have a mausberry available. My mausberry is just a lonley LED connected to GPIO

                      C 1 Reply Last reply 29 Sept 2017, 15:05 Reply Quote 0
                      • C
                        caver01 @cyperghost
                        last edited by 29 Sept 2017, 15:05

                        @cyperghost I hear ya. I am just trying to weigh the value for me. Right now I am satisfied with REBOOT=shutdown.

                        My 4-player cocktail style cabinet built as a custom "roadcase"

                        1 Reply Last reply Reply Quote 0
                        • C
                          cyperghost
                          last edited by 29 Sept 2017, 15:26

                          @caver01
                          Maybe for you ;) Because the whole approach could be made easier if you just invoke all coding to emulationstation.sh and then you would even have the choice what happens if ES shutdown and what happens if ES reboots. The only caveeat is, that you will loose the script after update (maybe chmod +i will help, I guess)

                          For me I state clear:
                          If I want to perform a software reboot - I want a software reboot
                          If I want to perform a software shutdown - I want a software shutdown

                          And till now the systemd handels all calls equal and this should not be the intention.

                          Personally it's not my responsibility to offer scripts here and to satisfy someones setup. It's an encouragement to learn something new and to share this knowledge for free as volunteer.

                          I think theres a real good chance to get the status of ES trapped in every situation and then handle this with a script - why not use this?

                          C 1 Reply Last reply 29 Sept 2017, 17:17 Reply Quote 0
                          • C
                            caver01 @cyperghost
                            last edited by 29 Sept 2017, 17:17

                            @cyperghost I don't disagree with your logic, and I definitely appreciate your insight and creativity with this challenge, not to mention the time you are spending to work out a solution.

                            Right now, I already have meleu's service running so nothing will be lost when ES updates.

                            Your solution would be additional software installed. Meleu's solution is additional software installed. From my perspective, it amounts to a similar obligation if I should need to reimage at some point. Yours has more capabilities, but is also more complex. Meleu's is simple, built from scratch using text files that I understand. I need to decide if I want to try a more complex solution, or use a working arcade system for a while and the only downside is that I cannot do a soft reboot. I guess I am saying that for now, I am OK with that.

                            My 4-player cocktail style cabinet built as a custom "roadcase"

                            C 1 Reply Last reply 29 Sept 2017, 17:57 Reply Quote 1
                            • C
                              cyperghost @caver01
                              last edited by cyperghost 29 Sept 2017, 17:57

                              Your solution would be additional software installed

                              Sadly yes

                              Meleu's solution is additional software installed

                              Yes that's the way with the best approaches - I always agreed.

                              I guess I am saying that for now, I am OK with that.

                              Yes, but my point of view is different. In RL I'm always confronted with such cases. There is a solution that works for an approach now. But someday there are changes in process behaviour and then a new solution is needed.

                              In worst cases there is no documentation available and you've to get inside and learn the process to understand. But pure hell to first deal with caveeats, edges, funds, process windows, frustrated co-workers, impatinet managment person and angry customers.... then after long time you might find a solution.

                              Best would be to elimante errors if they occour during the development/installing of the process. Then you have motivation, project refunds, teams and a target.

                              And I'm not talking about software development.

                              But it's okay, if you are satiesfied with this approach ;) And I'm glad that you have fun with your cabinet and that's the main thing why we are here active in this forum.
                              Don't waste a mind of mine time spending... All in all it took a few hours but over days distributed. As I started I was sure that this will be easy but it isn't. So it was clear ... no chance without a deamon :) That's because I've written please take the systemd solution and consider this as an approach how this can be done.

                              1 Reply Last reply Reply Quote 0
                              • L
                                lostless @DIY_glenn
                                last edited by 30 Sept 2017, 03:57

                                @diy_glenn said in Replacing Mausberry Script with a Python script:

                                But I've connected the Reset button on my NESPi to GPIO instead, so it can be used for something more useful. F.ex. one click = reset ROM, double click = reboot etc.

                                sorry all for the slight derailment, but this forum has no private message system. @DIY_glenn, im looking to do something similar with my reset button on my nespi but lost on how to hook up the gpio and how to wright a script. Many you can make a thread to explain how you did it and help us others out. I really want to learn this stuff.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                                Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.

                                  This community forum collects and processes your personal information.
                                  consent.not_received