External access to eGeoffrey



  • @user2684

    When I access eGeoffrey on my Mac via gateway.egeofrrey.com I see the heartbeat and the pushbutton. Also activity is displayed correctly.

    When I do the same on the smartphone I only have the pushbutton. The heartbeat is not visible. Activity of pushbutton is OK.

    When I go for editing the page the heartbeat is not available?????



  • Cool, it means it working then. As for the heartbeat widget in the mobile app, my bad, the mobile app has not been updated yet with the new gui, this is why it is now showing up correctly. I will publish by tomorrow.

    Out of the manual configuration, do you believe this capability (e.g. access from outside the local network without opening a port in the router or setting up a VPN) may be useful/interesting for a user? The automation piece is pretty demanding (new cli capabilities, a registration page, automatic provisioning etc.) so want to be sure it is worth the time I need to spend to implement it.
    Thanks



  • @user2684

    I think that with a proper Howto the user who has some experience with eGeoffrey can manage to come as far as we are now.

    Maybe one could indeed distinguish between a simple straightforward local installation and the more advanced set-up maybe with two different houses on the mongo db for the experienced admin.

    Give it some thought.



  • @user2684

    And for sure it is worthwile to make it available!

    And I do not think any further automation is required.



  • @user2684

    The first portion of the documentation I am working on is ready. I would like you especially to look into the introduction to be sure I got the quintesence correctly.

    Any comment is appreciated.

    Bringing eGeoffrey to the next level

    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.

    The next step is to have eGeoffrey with us when we are abroad. This can be done by using "the cloud".

    What we did until now is that we have eGeoffrey sending us an email when he needs our attention. Than we look into the system to see what is going on. That works well when we are within reach of our WiFi network or our LAN.

    It would be much more helpful when we could access the system being abroad.

    There are several ways to enable this.

    One way is created specifically to have eGeoffrey traveling along with us without creating an opening in our protected WiFi an LAN environment at home.

    It is possible to let our MQTT broker at home communicate with a publicly available MQTT broker in a protected secure way.

    While this broker is publicly available it can be accessed from anywhere.

    This facility is made available to have eGeoffrey traveling with us.

    To enable this possibility the "eGeoffrey app" needs to be installed on your smartphone. Next to that eGeoffrey needs a little extra tweaking.

    Installing the "eGeoffrey app" on smartphone

    I have an "Android" smartphone.

    Go to "Play Store"
    Search "eGeoffrey"
    Select "eGeoffrey" app.
    Select "Install"

    After installation go to Top right and activate menu.
    Select "About".
    Now the "Device Token" is presented. This veeeeeery long code has to be inserted into the web interface of eGeoffrey later on.

    Installing the "notification/mobile" module in eGeoffrey

    Got to "eGeoffrey/Marketplace"
    Scroll down until you see "egeoffrey-notification-mobile"
    Click on it.
    On the page where you land you are in the paragraph "Install"

    There you find the command which needs to be executed: "egeoffrey-cli install egeoffrey-notification-mobile"

    This command has to be executed on the Raspi with eGeoffrey installed.

    The simplest way:
    Open a terminal window on your network client.

    Issue the command:
    ssh pi@Raspi IP-address (in my case: ssh pi@192.168.2.160)
    You are requested to insert the password of the Raspi. Insert it.
    Now you can access eGeoffrey.

    Issue the following commands successively:

    cd egeoffrey
    
    sudo egeoffrey-cli install egeoffrey-notification-mobile
    
    sudo egeoffrey-cli start
    
    sudo egeoffrey-cli status
    

    Now also "egeoffrey_egeoffrey_notification-mobile_1" should be UP.

    Close the terminal window.

    Configuration of the mobile notification service

    Go to the eGeoffrey web-interface.
    Go to "eGeoffrey/Modules".
    Scroll down to "notification/mobile". Go to "Actions/Edit Configuration"
    Window "Module Configuration"

    Tab "notification/mobile"
    List of tokens of the mobile devices to be notified, comma separated (to get the device token, open the eGeoffrey mobile app and tap on 'About')

    Insert the "Device token"

    Save

    Now you are able to have on your smartphone the same interface as on your net-client.

    Top left open the three dashes symbol. Click on the log-in symbol. Now the eGeoffrey log-in menu is presented.

    Log in as the user of the web-interface in the WiFi/LAN environment. You have full access to eGeoffrey. Your smartphone is working together with eGeoffrey in a different way as via the Web-browser.



  • 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

    Thanks!



  • @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


Log in to reply