apostolakisl

I just installed the latest update. After the update, the only plugins that worked were the legacy pg3x. All eisy ui plugins failed. I had to reinstall every one of them which so far seems to be bringing them back to life.

To keep my life simpler and have my system backups be full drop in backups, I am installing all of my plugins from the store, even ones that are just for me. Initially I get something going as a local plugin, then I push it to github and put it in the store with status "new". "New" is not exactly the best word to describe what is really a development plugin, one that is only accessible to the developer. So while it is in the store and when installed on Eisy looks like any other store plugin, it doesn't appear in the public store. The installation of these is done from the developer section purchase options configuration page. Also, when I'm testing a plugin, it is nice to have it installed in folders with the same permissions that the public will end up with. I have had permission issues before where the plugin worked as a local plugin, but had permission problems when installed from the store.

If you have any questions or comments, please use this thread. Or you can PM me. Unless we find some bugs, I think the current release is the full feature release, and don't expect any further versions. But UD could also make changes that require changes to the plugin. If you installed the previous release, please see my notes in the other thread I posted. But basically, if you update, you will need to fully delete and install the plugin from scratch. But the latest release doesn't add any new features or fix anything, it just changes how the oauth with google is handled and you don't need to update at all if you don't want. Unless seeing that "update available" message causes you lost sleep. One comment: you will notice that if you manually run a backup using the eisy-ui interface that your backup is double sized. That is because this plugin saves the most recent backup on eisy itself (as well as pushing it to google/usb/nas). When a backup is triggered from this plugin, the first thing it does is delete the local backup so you don't keep get recursive backups inside of backups. Manually doing it from eisy ui won't delete that, so you will get one backup inside of the backup. it will never grow to more than that though. If you delete the plugin, that local backup is also removed. That local backup is accessible and downloadable via the plugins html page, should you want to retrieve it. The new version makes the plugins html page unnecessary if you only are interested in backing up to google drive. Google drive is fully configured now from the admin console or the eisy ui nodes page. You will only need to use the html editor if you want to push to a nas drive or a usb drive. Adding a usb drive also requires running a single command via ssh.

Yes, local plugins aren't part of a backup so I would assume that it would not mess up a backup. I have seen the 500 error twice and both times it was my fault because of something in my plugin. But the first I only discovered from a user of my plugin since I had it installed local on my system. I have switched now to developing my plugins via store installs. I start the plugin locally, push it to github and then post it to the store as "new" so it is not visible to the general public, then I push all my changes to github and do "reinstalls" as I work through the development.

I would say very nearly 100% chance. Good deal. Does this mean a permissions issue in a plugin gets ignored and everything else backs up, but the particular plugin does not get backed up? And if so, do you still get an error to know you need to fix something?

At present I can just pick any unused port and run a webserver which you deam a security risk and I don't doubt it. Perhaps you have a developer request form where developers request for a port to be opened. At present there is nothing stopping duplicate use of ports, so if someone else made an html page and by dumb luck picked a port some other plugin is already using there would be issues. The part that might hang you up is limiting use of that port to the specific plugin? Having port access in a plugin to run an interactive page is something that really takes plugin functionality and user experience up dramatically. I suspect I have just begun to touch its potential. Configuration of some plugins on eisy config page can really be intimidating. I suppose someone could make a helper app or html server separate from eisy that spits out a json file for upload to eisy config, but for something like ioxlogger nothing works but actually having a webserver on eisy. And if it is a config helper webserver hosted not on eisy and people put credentials in for whatever random thing, that is a different security issue. Plus it is just one more thing to confuse people or have issues.

The permissions issue involved FreeBSD NFSv4 ACLs, not simply the traditional Unix owner/group/mode permissions. The web_auth.txt file is located at: /var/eisyui/ns/plugin_<your slot number here>/data/web_auth.txt EDIT: just to be clear talking about eisy_Baciup plugin The file contains the plugin's web interface authentication credentials and is intentionally created with restrictive permissions (600) to prevent unauthorized access. However, the eisyui service runs under a different user account and could not read the file during a native system backup. It appears when a backup tries to access a restricted file, included in a plugin, it crashes the entire backup. Instead I would propose that the backup has fault tolerance. .. moves on excluding whatever it couldn't get access to and then logs an error that is as detailed as possible. The backup would presumably be restorable minus the restricted files.

ebay. https://www.ebay.com/itm/158227995166?_skw=opto+isolated+relay&itmmeta=01M70YQEZ25XQGEHJH2GQCVZFK&hash=item24d71f9a1e:g:CTIAAeSwGatqj7Fc&itmprp=enc%3AAQALAAAA8CHNgUiiE%2FjQhlDTaMiAde9OcepLcTNdjOjktOkpPc8015ATMF0gK%2FuiWaQIJOENMEwVDyUcrEB861hCSmXQF4aZrGcBcGPPoAArBmvo1ReMVMswjL8WT1SaNNIaNQIPV%2BS1MMbHUy5NwoKh9it4V03YD0YYMZTi2nYidlh6y6jXF2uffEqmW%2FCwxhmBR8OCFcY43V9kXe3LZP1uNMJuciS0ksW4gMkHcCPD%2BaQ2CFR2OvgzS57cBk7dvBvPLNOa2h0xvQTyNL1o2zfSEV%2FR6kHhxz9MzTFofowb5INRgbvfxuSOCrag8xNblb7szujnwA%3D%3D%7Ctkp%3ABFBM_O_dnrho If memory serves, webcontrol allows something like 20ma max per channel and 50ma total for all 8 at any time. I haven't really read through the linked item on ebay, but it looks like they are saying it pulls 5ma at 5v to trigger any one relay, so if I am reading that correctly, this would do the trick. Theoretically the opto isolated relays also greatly reduce risk of damaging the web control board should something go awry with the switched load on the main relay. You have to provide a separate power supply for the relay board which is where the power comes to drive the actual relay.

In creating plugins, I had introduced some bugs into eisy that not only caused problems in the plugin itself, but caused eisy ui backup to fail. I would think that a backup system should be immune to bugs in a plugin. The plugin bugs prevented the entire eisy backup from succeeding with an error 500. There were two node-server file-permission issues that caused the native eisy-ui system backup endpoint ( /api./system/backup/create) to return HTTP 500. 1. SmartLife/Tuya: The plugin's web_auth.txt file lacked the FreeBSD ACL permissions needed by the eisyui service account. Repairing the ACL resolved the problem. Subsequently added automatic ACL repair during plugin startup. 2. eisy Backup: The plugin's persist/backup_hisotry.json file could be updated or atomically replaced without preserving the required ACL. This caused an EACCES error during native backup. Corrected the file-permission handling in version 1.1.1. This bug only showed up in 1.4.9, not 1.4.8 Both problems demonstrate that files created or replaced by node servers can interfere with system backups if the eisy-ui backup process lacks sufficient filesystem access. It may be useful for the native backup process to identify the offending file and return a more descriptive error instead of a generic HTTP 500. It may also be worth reviewing whether the backup process should require access to every file in a plugin's persistent directory.

Topic wandered a bit. I made a plugin for eisy that backs up eisy, not ud mobile.

I have been migrating plugins over from pg3x to eisy plugins. Just did a sync on my ud mobile. And lost most of my favorites. I restored a backup and things seem to work, but I'm still working through if it is all working or if I'll need to recreate some stuff.

I made a plugin to do backups. Saves them to your google drive account. You can trigger the backups from programs, so easy to put on a schedule.

These are energy monitoring wall wart plugs. https://taskholt.com/products/aiseek-smart-plug-4-pack-with-energy-monitoring-15a-1800w-2-4ghz-wi-fi-alexa-google-assistant-programmable-timer-etl-fcc?shop_consented_scopes=email%3Averified+openid+pay%3Asession_token+profile+shop%3Aaccount_uuid&shop_sign_in=true After an hour of use, they do great. Going to use them to monitor washing machines for load completion and garage door opener for the door moving. And the price is right. Amazon delivered them in just 2 days even though I bought them on their own website. EDIT: These outlets are not quick enough with the wattage update to use for a GDO. Takes 5 seconds or so to update. It isn't a polling issue, directly polling the device every second and also watching the app which is subscribed doesn't update for 5 seconds or so. Totally fine for telling you when your washing machine is done. Probably a lot of things, just not something that needs sub 1 second accuracy.

That is exactly what I have set up with my elk. I don't use ratgdo since my gdo is 18 years old. I plan on adding wattage monitors to them so I know when they are moving.

I currently have an elk zone that monitors the garage door state and I use UD mobile to turn my garage door icon green when open and red when closed, but like I said, I plan to add that the door is moving to the mix (gdo is pulling > some number of watts). The issue is that my car automatically triggers the gdo when I drive away and so does arming my alarm system. So if the car has already triggered it and then the alarm senses it isn't closed and triggers it, it ends up reversing. So the added info of not closed + moving will be programmatically set to tell the alarm system to skip activation of the gdo and wait, then notify if it isn't closed. I also intend on shutting power off to the gdo when the alarm is armed in night mode and when I'm out of town.