sjenkins

I get the above, the last line will come up when I select any node except for the YoLink. It will repeat if I select another node. No additional lines come to the console when I select a YoLink node & receive no parameters.

yes

great job, I have status & properties on everything, Insteon, nodes, zwave except yolink devices from that node server, get a status but no properties on any devices

NOW I get it. I may be the only slow one but for others maybe. With eisyui service stopped it looks like before, listing my eisy with local ip and 8443 port. (Was going to insert pics but I can't upload files as the forum has been giving me 200 errors all morning) With the eisyui service running it finds my eisy with normal local ip and no port listed (assuming 80) I am understanding from bmercier that this is intended condition.

Just to explain again: I use 8443 with a local ip address and local logon I know 8080 is there as the base use but I thought with EISY that was turned off, so I don't use it. for some reason this "went away" in the AC logon screen & was replaced with the same local ip but with no port (80 I presume) that's where the popups show up. when I add back manually an 8443 with local ip, local login all is fine. I think the only oddball thing here is either with the new ISY or with the eisyui, it seems to be advertising the 80-port logon. if I use the non-local ipv6 ip and non-local login all is ok as well. not really a problem for an advanced user but will be an issue with others @GTench is this the same for you?

yes I am PM'd you my log from startup, login, to shutdown of service

That is after login and only on the one without 8443. Again the manually added one with 8443 works fine in the admin console. on the Eisy-ux, I think I did see status in the old version ; I can do control just fine. I didn't do any testing after changing to the new ISY version, worked fine before that, just don't know if something after that changed things.

So this is new as of today, see my IoX launcher, ignore the Polisy obviously. The eisy without the 8443 is populated automatically & if launched does not work properly, comes up with a: The one with the port 8443 I had to add manually and works as expected. Is this related to the last issue? btw: : I did do a reboot to "cycle the power". I did update my ISY to the 5.9.1_21 version. also, to answer one of your questions Insteon & plugin nodes, so all of my nodes show no status.

Yes, fixed, & thank you. Should the status column in nodes be populated? The controls work fine but the column is blank & in the details pop-out status is just shown by the label, no content.

@bmercier done.

@bmercier I upgraded to isy-5.9.1_21.pkg, needed to reboot to get isy service restart as it was Waiting for PIDS: xxxx forever. Didn't solve the nodedefs missing issue. When I do the "troubleshoot further" uri: https://eisy.local:8443/rest/nodes/55 79 DE 1/profiles it works fine and gives me data: {"timestamp":"2025-06-07T09:35:58.609185-04:00","families":[{"id":"1","name":"","instances":[{"id":"1","name":"","nodedefs":[{"id":"BinaryAlarm_ADV","properties":[{"id":"ST","editor":"I_OL_RELAY","name":"Status"},{"id":"ERR","editor":"I_ERR","hide":true,"name":"Responding"}],"cmds":{"sends":[{"id":"DON","name":"On"},{"id":"DOF","name":"Off"},{"id":"DFON","name":"Fast On"},{"id":"DFOF","name":"Fast Off"}],"accepts":[{"id":"QUERY","name":"Query"},{"id":"BEEP","name":"Beep","format":"/level/${c}/${c} ${v}/","parameters":[{"id":"","editor":"I_BEEP_255","optional":true}]},{"id":"WDU","name":"Write Changes"}]},"links":{"ctl":["I_CTL_RELAY_ADV"],"rsp":[]}}]}]}]} To be clear on the eisy-ux still getting: Error loading node 55 79 DE 1: Profiles loaded but nodedefs missing

Just got on board today with 0.4.1 & it sparked up without issue.... oh the potential !!! thanks @bmercier & UDI team !

Just wanted to let the crowd know about a known issue. Came up recently, but its not the first time. I have two hubs and when power is lost, cable is lost, or something else happens I can't identify ; sometimes one of the hubs does not come back & "loses master". Might also happen to one hub owners. So what that means is one of the hubs will be flashing orange/pink or just orange. The plugin locks with 'hub is not master' or 'hub doesn't respond'. Even with a cycling of the power on the hub or hubs, getting them back to blue status the plugin does not recover. Obviously I cannot fix the Hunter issues, unless I add a smart plug to cycle the power ; but I might be able to make the plugin more resilient. Just want everyone to know about it & as well ask if anyone else is experiencing this issue & can provide your context. Thanks!

See above. In my environment I am testing all the devices at once & seem to have a crash about once a month. Anyone else having this issue? If so can you send me what devices you are running & bonus points for logs (if you have them). Just had it crash when my cable company went up and down about a dozen times in the last few days ; was enough else going on that I haven't got to it yet, but this isn't the first time. Wanted to ping the user base. Thanks all !!

sorry I've been slow to respond ; been a busy week, @maxnorth you have a good link there the other way to get to that instruction is from the configuration tab of the MQTT nodeserver installed on your EISY. Basically you can use one of two methods to define your devices, deflist or devfile. The second is the one @TriLife was mentioning. The first is quicker/easier if you only have a device or two but the second is more sustainable over the long haul when you have lots of devices (the extreme being @TriLife). Don't worry if you use the devlist to start off you can easily switch to the other later. Hope this helps a bit. This is a pretty stable plugin now & more than a few people are using it for critical applications. Keep at it. Once you get the first one talking it will come pretty easy.

Yes, it will use the position (and all its other sensors) of the opener but you should read all the docs so you understand the compatibility to your opener. ratdgo is pretty flexible and works with lots of openers but you should understand that.

Rock solid. started out on the HA interface then moved to my EISY with the plugin. Using it for a couple of years now; I think. Long enough I don’t remember the last time I had to screw with the program. Depending on your abilities it can be finicky setting up the base unit but no touch after that.

This is the first time I’ve gotten a REST question on this plugin. You are correct it’s not in the docs, my memory was fuzzy enough I had to pull up the program to remember the command. You won’t find these kind of things in the WIKI for a plugin only in the config help or here on the forums. I can add it to the TODO to make it more match the norm, but would not remove this command as it would be a breaking change for someone. let me know how it goes!

DON and DOF are for full on and off setDim will set the level so to use your example: http://admin:<passwd>@192.168.0.xx:8080/rest/nodes/n006_90/cmd/setDim/128

A Polisy & an Eisy. Complete upgrade with no issues on both.

I am seeing $98.99USD for hub three & its available ; am I missing something? https://shop.yosmart.com/products/ys1605

I seem to remember that ns being to plug in a device directly to the 994 like a 1-wire temp sensor. In my mind I thought that any use case I had the device was remote from the isy. What is your use case? My use made sense to use a small WiFi or loRa processor ESP 32 8266 which then communicates directly to a variable with network messages . I have a few devices doing that. The code is c but could be made to work with simple parameters for variable and ip and password. Then your 1-wire can be farther from the eisy. anyway, interested in why a 1-wire connection to an eisy?

@zGuy981 good to hear. If you wouldn’t mind post your log here. I’d like to take a peek & may optimise.

@zGuy981 , thanks for finding this & the explanation. I did find the issue. Give the Beta a try & let me know, if all is well I will push to production if all is good , when I get back home next week.

@zGuy981 I’m travelling through mid week but will take a look at debug a bit today. I may have a few questions as on first read of description I am not quite following everything, but I’m in my phone.