External access to eGeoffrey

  • And for sure it is worthwile to make it available!

    Good feedback, I thought was something differentiating even if requiring some infrastructure behind the scene, I will prioritize this then.

    And I do not think any further automation is required.

    This is a precious feedback as well. Let me think of something in the middle. the most tricky part is for sure the user provisioning since I cannot manually create users and don't want to know any password but this can be done at a later stage. Maybe something which can be automated at this stage in a simpler way is the following:

    • Find a way to "merge" the bridge and gateway packages, there is no need to have two different packages and requires users to uninstall and install.
    • Have the installer asking for a house name so every user can be potentially on a different house
    • Have the cli allowing to rename the house
    • Have the cli allowing to enable/disable the bridge capability

    It requires some work but not that much to accomplish all of those. Long term I would like to have a registration form which creates an account on the clod broker. And in this way also there will be no need to use the token but the cloud service will know who is the user and the token will be automatically registered with the house. But this requires way more effort.
    Bottom line, let me quantify the effort of the points above since only those would dramatically simplify the instructions leaving only the "registration" piece out which is by now happening manually, in the future there will be a form.

    For most people the way eGeoffrey is working for us so far is quite OK .
    But he is by far not put to his limits.

    My feedback on what you wrote is definitely positive. Very clear, you entered into the mood ehehe and detailed all the required steps. If you want in the final how to add any picture, the error you faced with the forum has been fixed now.

    Probably how to expose the local eGeoffrey broker to the internet is something I need to detail somewhere better. There are this https://developer.egeoffrey.com/learn/deployment/ and https://developer.egeoffrey.com/learn/security/ which are related but not addressing it in full.

    will keep track of this need with https://github.com/egeoffrey/docs.egeoffrey.com/issues/3


  • @user2684

    Maybe another thought.

    A simple system could enable the user to manage his single house. He can use his smartphone to receive email notification and to use the web-browser to have a look what is going on. For this user the path into the (near) future would be the ability to take eGeoffrey with him travelling along. Here the access would be facilitated by the bridging function. That would complete the normal user's system.

    A second and more demanding system for you to make viable for the user would be a system that from the start aims for management of several houses. This would also require using the mongo db instead of the Redis one.
    Of course remote access via bridging would be required.

    The second option to go way beyond bridging by using much more the cloud would not be my preferred way. I am not a fan at all of the idea that everything is outside my control. (I do not like the cloud idea).

    The second system for the more experienced user will need support for the user to put the system on-line. I suppose here you would have to develop lots more than for the first system.

    This would provide a rather natural path of growth to a full blown multi premises system.

  • I believe the multi-house scenario is relevant but goes in parallel with the deployment option. Let me try to list some of the options so to make some order in my thoughts as well.

    Deployment Models:

    1. eGeoffrey is On-prem, notifications can reach you anywhere, web interface remote access via VPN or gateway reachable from the Internet
    2. eGeoffrey is On-prem, notifications can reach you anywhere, web interface remote access via the cloud gateway
    3. eGeoffrey is in Cloud (hybrid actually), reachable from the Internet by definition, house information pushed to cloud

    I'm not distinguishing here between web app and mobile app since they are kind of the same. For scenario 2) I can make just a gui accessible somewhere like web.egeoffrey.com and would provide the same capabilities of the mobile app since the gui per-se is just a presentation layer.

    For the multi-house discussion, mobile notifications are already supporting this scenario, e.g. you can get notifications for multiple houses (the house name will show up on top of the notification and are grouped already together by house). This is because the notification is pushed by eGeoffrey wherever it is regardless if the mobile app is logged in or not (this is because otherwise notifications wouldn't work if the app is paused by the OS).

    For the web interface point of view, we are half the way since you can log in into multiple houses from the same web interface but you need to login and logout everytime. An easy way to switch between configured profiles could be the way to go. This applies for both the web interface and the mobile app of course.

    For the engine itself, there are no problems, if you want to run multiple houses on the same machine you can, just configure different ports. Even the database is not an issue here since every house is running in an independent network so you can have different redis running and not interfering one with the other.

    The mongodb thing was instead introduced for a single reason: if setting up a cloud server (so scenario 3) running multiple houses can still use different redis but it is not convenient money-wise to make users consuming the memory since storage is cheaper. On the other scenarios, also one house or multiple houses, redis is way more convenient and light-weighted. I should probable take the mongodb package out of the marketplace since could be a distraction.

    A sub-scenario of the multi-house is having in the same eGeoffrey house two different locations. But this is feasible as far as the eGeoffrey engine resides somewhere and the second house has another raspi which is just collecting data and connected to the same primary gateway.

    Bottomline, a user can choose one of the three delivery methods above, the first one is fully available, the second one partially, the third one not yet (and will be only if there is any interest).

    For multi-house, technically the only gap I see is a fast switch between multiple houses.
    Makes sense all of this?

  • @user2684

    I was indeed mistaken by my understanding that for managing more than one house the MongoDB would be required. This not being the case, forget the mongo as far as I am concerned.

    Having stated that, the whole lot seems to become much more simple.

    I would like to picture two scenario's which could make starting with eGeoffrey for the normal user and the more experienced user a bit easier.

    The simple version is the user with one house, traveling around with eGeoffrey and having full access to him.

    The more advanced option would be the user with his main residence and a holiday home.
    He is controlling both houses while he is traveling around with his smartphone as mr eGeoffrey

    If you/we would be able to create a setup with accompanying Howto I think eGeoffrey can have an easy start with most new users.

    The user finds a lot of howto's now to extend the possibilities after having implemented the first simple scenario.

  • @user2684

    Something else crossed my mind.

    When it would be the most simple way to install just one raspy in each house and treat both individually without further integration of the software side, let's just say so.

    Let's not make it more complicated than necessary.

    Just show/tell the user how to solve this situation such a way that both houses are controlled while travelling.

  • @eporocrail said in External access to eGeoffrey:

    I was indeed mistaken by my understanding that for managing more than one house the MongoDB would be required. This not being the case, forget the mongo as far as I am concerned.

    If your understanding was mistaken just means this was not explained correctly so good discussion for me anyway 🙂
    Glad it makes more sense now, this would be another piece of documentation to add eventually (https://github.com/egeoffrey/docs.egeoffrey.com/issues/4) .

    What you are referring to in your last post is very close to the sub-scenario mentioned above which is actually something I never through about but could be expanded and documented better since sounds like a pretty common requirement.

    From an implementation point of view is actually very similar to the cloud scenario but the instead of having a cloud provider, the primary house is the cloud provider. Which means a raspi on the primary house with a normal install deployment and another raspi in the holiday house with is using the primary house as bridge (some sort of DDNS or static ip address has to be used of course).

    I believe (but this has to be tested), the cloud gateway can be also used with both houses bridging into the same of course always using the same house id.

    Anyway, any example or documentation around this scenario would be for sure useful and precious!

  • @eporocrail said in External access to eGeoffrey:

    When it would be the most simple way to install just one raspy in each house and treat both individually without further integration of the software side, let's just say so.

    You mean just keeping them completely independent? In this case you would just need to logout and login pointing to the other house's gateway (as long as it is reachable) from any web interface or mobile app instance

  • @eporocrail FYI the updated mobile app has been pushed to Google Play so you should get it shortly (in case do a manual upgrade from Google Play directly). Thanks

  • @user2684 said in External access to eGeoffrey:

    You mean just keeping them completely independent?

    I mean let's not make it more complicated than necessary. KISS.

    If two separate installations would do the job perfectly, let's not exclude that option on beforehand.

    I think that eGeoffrey can do a great job in such an environment. You are the one and only who can make it happen in a way the user can implement it in a way which is not so overwhelming that he is not going to explore the real possibilities and power of eGeoffrey.

    The user should be seduced to explore further possibilities after an easy entry with a realistic and useful scenario to get acquainted with our electronic friend.

  • @eporocrail said in External access to eGeoffrey:

    I mean let's not make it more complicated than necessary. KISS.

    Good for me keeping the KISS approach 🙂 I tend sometimes to make things too complex but I believe this other approach is what we need right now. Let's make the two houses as two different instances for now. I probably need to prioritize the house switching, even if not strictly required (https://github.com/egeoffrey/egeoffrey-gui/issues/49). Thanks

  • @user2684

    I prepared a second Raspi.
    It is a model 3B and not a 3B+. Booting from USB is possible but rebooting does not work with me. I just took an SD card again. That works. Rebooting is OK.

    With this second raspi I am going to control my main house. The first one will be my "holiday home"

    Thinking about two houses it crossed my mind that in the allocation of topics to the sensors the first part of each topic should reflect the house. If this is not done, I suppose I will get in trouble because both Raspi use the same broker in my LAN.

    In no way it will do any harm except for the need for a few more bytes transferring the topic. And this is no problem at all.

    So the next steps will be to adapt my topic naming convention and to make a second sensor decoder with heartbeat generation.

  • @eporocrail sensors, rules, pages and any other configuration item can be structured in the way you like. My preferred format is "parent/child" but can be any. Under the hood the "/" will create an actual directory on the filesystem so to have the configuration files hierarchically organized. If "parent" is the name of house, the floor, the measure is completely up to the user. So you should be ready to go. It is just unclear to me if you are targeting to keep the two raspis completely independent as mentioned last time or to have them communicating together. If independent but using the same mqtt broker, you just need to use two different house id in the configuration and they will not overlap.

  • @user2684
    I will keep them completely independent. I want to have this set-up to perform more testing for the aim we have.

    I am using two different "house id's". That means that I do not have to adapt my topic allocation method.

  • @user2684

    On second thought I think that in my case I do have to prefix the house-id because my sensors communicate via the same broker. When I do not prefix the house one sensor message is accepted by two raspi I guess ?????

    Two raspi and broker are on the same LAN.

  • @eporocrail if understood correctly, no prefix is needed, if you use the same broker with two different house id, there will be no issue at all

  • Some progress on streamlining the process for using the cloud gateway:

    • egeoffrey-cli (v1.0-27) has now a new command called "setup". This will ask for the user the house identifier and if willing to connect to a remote gateway and if so its configuration interactively. This information is saved in the .env file so no need to change anything manually for the user like you had to do. The setup can be run at any time to change the name of the house, enabling or disabling the remote gateway connection. To upgrade the cli run sudo egeoffrey-cli upgrade
    • Also the installer now leverages this setup when installing eGeoffrey so the user will have at the beginning and after the same experience
    • The egeoffrey-gateway (v1.2-1) package now provides the same capabilities of egeoffrey-bridge. When the service is started and the remote gateway is configured, it generates the configuration based on the information the user provided in the setup previously run. So no more the need to switch between packages. Of course when you change anything with setup, you need to restart the gateway to apply the changes. Other minor difference compared to previous version in which the mosquitto configuration was persisted on data/gateway/config, now this is not happening anymore by default so I can generate the configuration files on the fly based on the user settings. For backwards compatibility, when the directory is mounted, the provided configuration is used as is. So for any user upgrading it is recommended to uninstall and then install the package before running egeoffrey-cli update
    • The egeoffrey-bridge package has been deprecated and removed from the marketplace

    Hope after these changes the process is better for any new user 🙂

    In your specific scenario, what I suggest to do is the following:

    • sudo egeoffrey-cli upgrade
    • sudo egeoffrey-cli stop
    • sudo egeoffrey-cli uninstall egeoffrey-bridge
    • sudo egeoffrey-cli setup
    • sudo egeoffrey-cli install egeoffrey-gateway
    • sudo egeoffrey-cli update
    • sudo egeoffrey-cli start

    This should clean up any manual configuration I asked you to do.


  • @user2684

    Let's get started.

  • @user2684
    The remote house is OK. Fully accessible. I did introduce the prefix of the house. Because of that I created two new sensors, heartbeat and pushbutton. I put them on two separate pages. Everything is working.

    Up to the second raspi/house

  • @user2684

    Did a new install on the second raspi. I like that "sudo egeoffrey-cli start" is not required anymore.

    Than I had no access to the website.

    After deleting the browser history problem was solved.

  • @user2684

    smtp problem

    I wanted to configure the smtp module for the second house. Looking up the values in the first house:

    in the "template" field:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


Log in to reply