Custom component: EdgeOS

bar · February 11, 2019, 5:52pm

The reason why it failed in device_tracker/edgeos.py in line 37 is because the component was not loaded, can you check:

Were there any other errors / warnings before related to custom_components.edgeos?
Are you on the latest version (git pull)?

Certificate file is optional:

CONFIG_SCHEMA = vol.Schema({
        DOMAIN: vol.Schema({
            vol.Required(CONF_HOST): cv.string,
            vol.Required(CONF_PASSWORD): cv.string,
            vol.Optional(CONF_USERNAME, default=DEFAULT_USERNAME): cv.string,
            vol.Optional(CONF_SSL, default=False): cv.boolean,
            vol.Optional(CONF_CERT_FILE, default=None): cv.string,
            vol.Optional(CONF_MONITORED_INTERFACES, default=[]): vol.All(cv.ensure_list, [cv.string]),
            vol.Optional(CONF_MONITORED_DEVICES, default=[]): vol.All(cv.ensure_list, [cv.string])
        }),
    }, extra=vol.ALLOW_EXTRA)

I will get back home soon and will check it without the cert_file (weird just because it’s not being used at all just for variable assignments)

Thanks

salle · February 11, 2019, 6:09pm

…I was going to ask a stupid question, it became apparent I had copypasted the edgeos.py from github and got all the html code to the file in the process which resulted in weird errors…

Anyway, now I’m running to the error having not specified the cert file - is there some specific configuration I should do? ssl: true or false? Anything else?

bar · February 11, 2019, 7:10pm

@salle, checked it and I missed the default settings in case it was not provided (kind of missed the concept of making it optional), please pull and check again (tested in clean VM environment)

bar · February 11, 2019, 7:20pm

Please wait with pull, found an issue, working on that

bar · February 11, 2019, 7:51pm

Added better error handling for empty messages from websocket and when there’s an error, it will be logged with line for all kind of exceptions.

salle · February 11, 2019, 8:04pm

Okay, now I got it working. I had to enable SSL because ER-X doesn’t allow connections without it. Nice! Have to dig in deeper tomorrow, thanks!

stevenhorner · February 11, 2019, 9:38pm

@bar upgraded to the latest version and same problem. Created the command line sensor and got the following error:

Command failed: ‘pip freeze | grep websocket-client’

Just thought I better explain my hass.io install in case it makes a difference.
I’m currently running version 0.84.6 in a VM with Ubuntu 18.04.1, installed as per the hass.io instruction for this case. I’ve been running this for several months upgrading hass every few weeks. Just not taken the plunge to have lovelace the default yet, so a couple of versions behind.

grantc · February 12, 2019, 4:56am

Thanks bar, whatever change you made overnight has fixed the problem. Thanks again

bar · February 12, 2019, 7:24am

I will try later today to install hass.io at home to check that issue and will update you

salle · February 12, 2019, 3:59pm

Okay, I had EdgeOS running for the last ~14 hours, after some time it started getting errors connecting to the router - the HA log was filled with those, and the histograph I have didn’t update. The router was accessible though - I’m not sure but could be that HA just got too much data from the router(?).

I was stupid enough to not grab the exact error message - I will get that should it happen again. After restart of the docker it started working again.

I know you’ve just started developing and don’t know if this is the right place for feedback, but I would probably change bps to mbps, and change (or make configurable) the update frequency of the data (as to not bloat the HA database with the data). Not sure how the data updating works and what is doable, but these are just my quick thoughts on it anyway, nice work!

bar · February 13, 2019, 7:20pm

I found an issue with closing threads that might cause that kind of issue, fixed it and it seems that now it works much better and faster.

In addition, thanks for the idea of update frequency, add it as well.

As for unit of measurement, I will add it during the weekend and will update you

You can pull the latest version with the 2 fixes above

salle · February 14, 2019, 6:07am

Installed the new version.

I noticed that interface rx/tx bps disappeared on the way - can’t see that in the sensors any longer.

The history component still goes nuts after only an hour or two, since there are so much data points. I don’t know would it help to change cpu/mem/uptime to a graph (probably not), but a graph would probably be a better indicator for those anyway. Just for considering in the future

It’s a shame that if you exclude entities from the history component, you cannot use them on a lovelace card by itself. Because I don’t think the amount of data points itself is the issue, it’s trying to load the history page with loads of entities that each have massive amounts of points. I hope I make sense , time to wake up…

bar · February 14, 2019, 9:47pm

New version:
Expose 1 sensor per device / interface / system with all its details (instead sensor per measurement)
Update components only upon interval (system sensor and unknown updated as you mentioned all the time - fixed)
Add CONF parameter for units, optional, accept the following values:
‘’ (empty string) - represents bytes
‘K’ - kilobytes
‘M’ - megabytes

thanks for all the feedbacks!!!

stevenhorner · February 15, 2019, 4:23pm

Did you get chance to try it on Hass.io?

bar · February 15, 2019, 7:12pm

Not yet, hopefully will get to it tomorrow

salle · February 16, 2019, 6:23am

Okay, new version running, I had this issue where I tried to exclude sensor.edgeos_system_uptime
from history (loading up the history took a really long time) but I guess it was either the data that had already been logged to yesterday or it had something to do with the browser cache, because now mem and cpu are gone from the history. However I can still see the uptime itself in history climbing today, even after the change of date in history page.

Other thoughts:

Mbps is still shown like this: MBps (Received) 1188036608 so the conversion isn’t working correctly (I don’t have this fast connection )
Now that the most of the interface data is in one sensor, it’s not possible to create a history graph for most of the data in the sensor. I can see the current data of bytes received, bps etc. but the only thing that is recorded is the state of eth0 connection

tom_l · February 16, 2019, 6:32am

Owch. I just tried it with hassio and I lost access to the frontend. Fortunately SAMBA and SSH were still working so I removed the config and files and restarted. One browser refresh later and all is well again.

I had moved the required files to the required locations and added this to my configuration.yaml file:

edgeos:
  host: !secret edge_os_host
  ssl: false
  username: !secret edge_os_username
  password: !secret edge_os_password
  monitored_interfaces: 				
    - eth0
  unit: 'M'

Secrets were also defined appropriately.

bar · February 16, 2019, 8:20am

I merged all data related to a device / interface under one sensor with all the attributes that represents the data that was previously in different sensor,
same for the system sensor, this time it represents the uptime with attributes of memory and CPU.

on top of those changes, I change the flow to update the sensor upon update request (time based by default 60 seconds, can be updated as all other sensors available by changing the scan_interval configuration).

the reason why I’ve done it is to reduce the number of items it creates until I will add the ability to define which parameters the user would like to get (from a list of predefined values).

As for the calculation, I will check it, when did you take the latest from GitHub?

Thanks

bar · February 16, 2019, 8:20am

Do you have any logs that will redirect me to the issue?

thanks

tom_l · February 16, 2019, 8:23am

Unfortunately not any more. I’ve restarted many times since then implementing an SNMP method.