Get rid of "examples"

  • @user2684

    I did what you advised.

    We addressed under "back-up" the fact that after reloading a back-up a part of the system (menu structure) was gone.
    Well, surprise surprise, that old structure popped-up now again.
    So far so good, but the worse part of the story is that the part of the menu structure relating to my sensor control page is now gone.

    It will fore sure still reside somewhere bur I have no clue how to access that page.


    P.S. I am waiting until you react to be able to answer questions from you. My work is put on hold.

  • When you use "SSH" go to the "egeoffrey" directory and "sudo nano .env" will bring you where you need to be.

    Makes sense since dotted files are usually handled as hidden by unix OS, you may not see them with a "ls"

    So far so good, but the worse part of the story is that the part of the menu structure relating to my sensor control page is now gone.

    A few things to try:

    1. Ensure your page is somewhere within data/egeoffrey/config/pages and data/egeoffrey/config/menu. If you backed up the entire directory there is no reason why should not be there after a restore
    2. Try cleaning up the cache of the browser
    3. Try adding in your .env file EGEOFFREY_CONFIG_FORCE_RELOAD=1 and restart. On startup, controller/config is responsible to push to the mqtt broker all the configuration files; this directive force cleaning up everything retained in the broker before pushing it again. The process can take a couple of minutes. If works, remember to remove the directive from the .env file to avoid the process to be repeated at every restart
    4. Try changing your house id. The latest CLI does not allow you to do it easily but you can add to your .env file a EGEOFFREY_ID=new_name and restart. This will cause the configuration to be pushed to a different mqtt location

    Of course options 3 and 4 makes sense if your configuration file is there as I expect.

  • @user2684
    I checked if the pages are there. Nope.
    I cleaned the history. Nothing.

    I will restore the back-up I created of my new system with the control page first.

  • I checked if the pages are there. Nope.

    That's completely unexpected, if the pages were saved correctly the files must be there, the whole configuration is flat and based on files which are in a dummy way just read and pushed to mqtt

  • @user2684

    My back-up does not contain the right pages and menu. Also the sensors are not available.
    What went wrong I do not know. Maybe I backed-up to early in the process.

    One should learn from his mistakes.

    Main lesson is to have the right back-up procedure and frequency in place.

    Second lesson there are no problems only challenges.

    Third lesson rehearsal supports learning.

    I am going to do it all over again.

    First of all getting rid of the example stuff.

    On a second raspi I have the examples.

    Start with a clean menu structure and build that first.
    Than generate all sensors.
    Than procede page by page.

    Last lesson: documentation is SO IMPORTANT.

    Should I perform your points 3 and 4 first or should I just go ahead?

  • My back-up does not contain the right pages and menu. Also the sensors are not available.

    You cannot imagine how sorry I am that you have to start from scratch 😞 I really have no explanation for this to happen. If there is no file, there is no page and viceversa, theoretically has been built that simple to avoid this kind of issues. Really hope it will not happen again.

    Should I perform your points 3 and 4 first or should I just go ahead?

    No need for them, those are just alterative recovery methods in case the configuration is not applied despite being there.

  • @user2684

    Did a new install. Followed your advice to get rid of the "example stuff". It works. Everything is gone, also after stop, start.

  • @eporocrail let me pick your brain on this topic since I'm struggling to find a solution which is effective but does not require too much refactoring. A few constraints first:

    • Examples are like any other configuration files, every time a module starts or restarts, if there is any embedded configuration file including an example, this is added to the manifest and pushed to the gateway. On the other side, controller/config receives the manifests and for every configuration file which does not exist, creates it. This means I don't have control over the first part (unless changing the SDK but not worth of it) but I can play with controller/config in case
    • There is no real uninstallation process to potentially use to delete deployed examples since when you run egeoffrey-cli uninstall, it just prevents the service from running, there is no interaction with the running components.

    Given the constraints above I am evaluating the following approach:

    • Examples are placed in a special folder so in the GUI I can distinguish them and place under a dedicated section, not under my house which is left to the user. Makes more sense in this way from your point of view?
    • Examples could be read only since everything can be cloned now
    • For deleting all the deployed contents (not only pages but also sensors, rules, etc) the only way I found is adding a specific action in the GUI under eGeoffrey / Packages to delete examples for each package the user can trigger. However, if the module is restarted, the contents will be deployed again. Also, the user should remember to click on this option before uninstalling the package which is a bit cumbersome
    • Alternatively I can prevent examples to be deployed by default and having instead an option for installing them through eGeoffrey / Packages. But for a new users, this would require too many steps to have access to basic examples which are I think important for new starters.

    Any thoughts on this?

  • @user2684
    At the moment I am working with 50 sensors. That was the reason I wanted to get rid of stuff not relevant for me anymore.

    As you put it I would do the three things you propose together:
    place the examples read only in a specific folder outside the user environment and create a specific action to delete all example stuff.

    To me it is not clear why it needs deleted before uninstalling a package.
    Even when the user forgets it there is always the way via the advanced editor to remove unwanted remnants.

  • @user2684
    Some afterthoughts. When things are "read only" deleting might be a problem.
    Besides that maybe there is something you could do with adding the instruction to prevent the examples being created to the configuration file of the I think controller. I do not know if you could do that in a script or not. Otherwise you could incorporate that in the text you have to create to explain the topic.
    I think that people who want to get rid of examples are knowledgeable enough to use the advanced editor.

  • @user2684

    I meant :

    Try adding in the .env file the following and restart eGeoffrey (😞

    Remember this will be overwritten if setup is run again. Once restarted you can delete the examples and they will never show up again.

  • Thanks for the feedback so to summarize:

    • Examples will be placed in a dedicated area, not mixed with user defined pages
    • If possible will be made read-only (by read-only I mean user cannot change the content but can of course delete the files)
    • Examples, like any other content can be deleted individually (no more the need to use the advanced editor since any content can now be deleted outside it)
    • There will be the way to delete all examples (pages, sensors, etc.) belonging to a given package from "eGeoffrey / Packages". Of course those will be recreated if the package is restarted. Once a package is uninstalled, examples cannot be deleted any more with this method (since the package will not show up anymore in the gui). Still can be deleted individually
    • egeoffrey-cli capable of setting advanced parameter in the .env file without the user to open it so to allow the user to set EGEOFFREY_CONFIG_ACCEPT_DEFAULTS
    • Documentation to be updated accordingly

    Sounds reasonable?

  • @user2684

    I think no wish left.

  • This is now addressed in v1.3-7 (development). I ended up with the following:

    • Examples are no more under MY PLACE but are located just under the welcome menu folder (creating a independent section for the examples below the user pages as originally planned revealed a bit confusing - examples for new user should be before custom contents - and would have created some compatibility issues - existing packages already have examples and many changes would be needed).
    • Examples pages cannot be edited and renamed. Users are supposed to clone the pages if needed (for now I'm ok sensors and rules can be changed)
    • All examples (sensors/rules/pages/etc) brought by a package can be deleted from "eGeoffrey / Packages" with the action "Delete Examples". Of course if restarting the package would bring in again the examples

    How does it look like?

  • @user2684
    Looks great!

  • @user2684

    I am trying to create a stand-alone local system. I did away with all examples (took some time). Also edited .env. Yesterday it was running OK. Today no Mqtt traffic in both directions.

    Did an update.

    All example stuff was there again.


    Would it be possible to create a way to do handle examples the other way around: standard no examples and when the user requires it the examples are added (after a selection and followed by an update?)

  • @user2684

    The other and I suppose more realistic approach would be to finish the system and when ready than do away with the example stuff.

  • @eporocrail said in Get rid of "examples":

    Did an update.
    All example stuff was there again.

    This should not happen. If EGEOFFREY_CONFIG_ACCEPT_DEFAULTS=0 is set the only thing which makes this setting going away is running "setup" again. Updates and restart should not have an impact. Are you sure EGEOFFREY_CONFIG_ACCEPT_DEFAULTS has been set correctly?

    Still I understand examples are not yet managed smoothly. Let me try to rethink a better approach ( . Unfortunately, since this should be a setting of controller/config and controller/config is supposed to push configurations out, I have no easy way to configure the configurator.

Log in to reply