apostolakisl

did you use https:// your screen shot shows http://

Are you running 1.1.0 or 1.1.1. I had that issue as well and thought I figured it out and fixed it with 1.1.1. I'm hoping you are 1.1.0 cause if not I have to look at that some more. The plugin was running and logging, but the html wasn't working. Currently I am not having issues running 1.1.1. EDIT: I see the issue, https:// not http://

I added logging of programs to IoX logger. No more frustrating only getting to see the last run of a program when debugging a misbehavior. You can see all the runs and whether it ran then/else. It is all handled through the html interface at port 8765 as before. It will log all program activity when enabled for a selectable period of time. You can search the log within the html window, or you can download a csv file and use your preferred program to organize and search it. I also added authentication to open the html control page. To enable the logging, you will need to enter your LOCAL iox username (admin) and password. Not the portal credentials.

I appreciate what you are saying. But in my case, many more than 5 minutes passed. I didn't do a reinstall all, I reinstalled one at a time. And I missed a couple. Like an hour later I was checking things out and discovered the ones that I missed still not working. Reinstall fixed them. Not the end of the world since a re-install is a benign action, but still. Also, at midnight, it looks like I may have had a double run again of my MN programs. It is possible that the false run of the program was earlier in the day and associated with a reboot after the update. Though a reboot or update should not trigger a program that is scheduled to run at MN to run when it is many hours before MN. I assume that all program runs are in a log somewhere via ssh, but from admin con I can't tell anything but the last run.

Restarting did not work. Restarts just made the "connected" green logo blink. I had to reinstall. Reinstall in reality is not meaningfully different than restart, but still, indicates a deeper issue. Unless you were running an older version of the plugin and didn't want to update.

I forget what version I was on before the eisy update, but it was maybe whatever was current as of last weekend. All of my eisy plugins after this update failed to function. Hitting "restart" did not do the usual restart of seeing it stop/start/connect. They instantly showed "connected" after hitting restart and they still didn't work. I had to reinstall every one of them. That includes plugins that were not migrated pg3x plugins, ones that were originally installed as eisy plugin. That included local plugins in eisy plugins as well.

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.