swnewman

Ticket opened. Thanks for your help.

sudo uname -a FreeBSD eisy 13.1-RELEASE-p5 FreeBSD 13.1-RELEASE-p5 #7 releng/13.1-n250174-753d65a19a55-dirty: Sun Dec 4 06:58:17 UTC 2022 root@bsdev.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64 sudo tail -f /var/udx/logs/log Thu Apr 6 18:52:11 CDT 2023|/usr/local/etc/udx.d/static/udxops.sh: checking whether or not we have a new version for udx ... That was the entry that came up right after hitting upgrade packages. I waited over 10 minutes and it never gave a new message in the log. I know there is a warning sticker on the eisy about heat dissipation, but this thing is quite warm for not having any real load yet!

The portal tab shows the device as offline, with only the option to refresh. I don't see a way to approve it. I can try to ssh into it tomorrow. What are the remedies if I am in an endless upgrade loop? It seems very strange though for a brand new device to have very old firmware.

I recently purchased an eisy to replace my isy944i. I managed to get it onto the network and can launch the admin console to show the IoX. When I first login to IoX, it asks if I want to install the ISY Portal module. I say yes, and it thinks for some time and eventually comes back with an error every time. I believe I've seen 3 different error messages but I attached a screenshot of one below. Also, since I will be eventually transferring my ISY994i to this eisy I wanted to get the eisy on the latest version. When I go into config and click Update Packages, it asks me to confirm and says I will hear 4 beeps when it is done. I click yes and it immediately closes the admin console. I wait and wait, but I have never heard any beeps coming from the eisy. I wait some more and reopen the admin console and nothing has changed. And it still wants me to install the Portal module. Can anybody tell me what might be going on? Is there a way to manually update an eisy?

Thanks for your help. I've told Mike that I can write up something if needed.

Actually, I got it working finally! I had a problem with how I was parsing the feedback, but now I see all of the messages coming across. I think I still get errors in the log, but I'm getting feedback anyway. Quick question: For updating the state of my devices, I'm guessing I should use the events listed as "ST". Is that correct?

Is there a separate command for "listen mode"? All I do is send the subscribe command and wait for a response on the screen in a feedback textbox. I saw no response to the subscribe command or subsequent ISY update events. The feedback textbox is set to listen for any response (i.e. no parsing). The other user who got this working has shared his setup in the iRule library. I'm going to import his version, when I get the time, to see if I missed anything in the setup.

Well the error log is now working again. I guess maybe there is some delay before it is available.

Okay, another iRule user tackled this and managed to get it working using a TCP gateway in iRule versus HTTP. I've followed his instructions and it looks like I'm getting a good connection to ISY for sending the subscribe command, but I don't appear to be getting any feedback. I just checked the error log after multiple times pressing the button to send the subscribe command and I see errors like the following: -170001 [uDSockets] RSub:32 error:6 -5012 30 -170001 [uDSockets] RSub:33 error:6 -170001 [uDSockets] RSub:33 error:6 -5012 31 -170001 [uDSockets] RSub:33 error:6 -170001 [uDSockets] RSub:33 error:6 -170001 [uDSockets] RSub:33 error:6 -170001 [uDSockets] RSub:33 error:6 Does ISY think the socket is closed? I did notice my rest/subscriptions now has two unexpired subscriptions amongst the expired ones. <Sub isExpired="no" isPortal="no" sid="33" sock="33" isReusingSocket="yes" isConnecting="no"/> <Sub isExpired="no" isPortal="no" sid="35" sock="30" isReusingSocket="yes" isConnecting="no"/> On a related note, I decided to clear my error logs and since then every time I press Error Log in the Tools menu it says Request Failed! Is this a bug? I've tried creating more subscribe errors but now it seems I can no longer get the error log to download.

I'll check the logs. Is there a certain command that instructs the socket to remain open? Email sent.

Michel, I still haven't had much success with this. I've tried browser-based plugins on my desktop to try to help me understand the web service subscription outside of the iRule application. As shown in my first post, I can send a subscribe command and get back a "Status 200 OK", along with some xml containing some sort of ID. This is where I hit a road block. Once I am "subscribed" successfully, in theory I should be able to receive event-driven responses (i.e. a switch turning on or off), right? I get no other notices to my desktop when devices are updated in ISY via a switch. Is this even possible in the browser-based approach I am using? Or could you suggest another tool more appropriate to the task? I tried one tool recommended in the wiki but I wasn't even able to get the "Status 200 OK" response to my subscribe POST message. Perhaps I am missing some key piece of knowledge to get this working. Maybe the socket? I am simple following the tutorial for the subscribe command and entering "REUSE_SOCKET" for the report url. Please let me know if that's not right. Sorry for all the questions, I hope you can help me get this working. I've asked for help on the iRule forums but nobody is able/willing to help me. I'm sure it's something simple I'm missing, unless they do not provide the ability for the end user to subscribe to ISY feedback outside of their separate ISY module. That's why I kinda want to get this working outside of their app just to better understand the process. Thanks for the help. -Seth

iRule has an ISY module which I'm sure is set up to work with the web services, but it is fairly limited on how you can design with it. (Trust me I would purchase the module if it would work with my design, it would be so much simpler.) I am trying to do it with the built in http gateway capability. Everybody keeps saying it should be possible, but I have yet to run into anybody that has actually done it.

In my quest to get the iRule app on my tablet subscribed to ISY messages, I've had to try to figure out ISY web services. Without much familiarity with SOAP or WSDL, I was able to do the following from a desktop browser: Using the Postman extension in Chrome, I posted the example SOAP subscription xml to ISY /services. Attached shows the screenshot results of that. Essentially I get a Status 200 OK and some response xml. Assuming that means I have successfully subscribed to ISY, how would I go about viewing messages that should be now flowing to my desktop machine every time ISY records an action? I would like to see the format of the responses to, say, a light switch turning on. I assume it is xml; does it follow the same format as the REST responses? I need to know in order to be able to parse the feedback in iRule. On the other hand if anyone has already gotten subscription to work in iRule, I would welcome any pointers. So far I have not been successful. Doesn't seem like I am getting the gateway and/or command set up correctly. Thanks for your help. -Seth

If you have the URL to the stream on your network, just creat a URL widget with that link in it. Then you can size it to a size that makes sense for the video resolution. That should be all there is to it. You may have to look at the camera's web interface source code to find the URL, or google it. It's camera/brand dependent.

iRule can control almost anything you can send a command to. For cameras, you can add a URL widget with the link to your cameras stream, and then add buttons that have the commands for controlling it. I haven't gone as far as adding the buttons, but I have integrated the streams into my handsets just to get a quick view. The only caveat is MJPEG is not supported. If you have H.264 cameras you should be fine. Also, you can of course control ISY in iRule through the REST interface. This gets you around having to buy the module. I've found some of the customization of the module to be limiting. The only issue with using buttons for ISY in iRule is that device feedback becomes much more complicated. I think they are working on allowing feedback to alter what image is presented on the button.

hart, I believe this is a known issue without much of a solution other than turning off your Query All. See viewtopic.php?f=27&t=10765 The bottom line is the ISY ends up receiving to responses from the IOLinc that arrive out of sequence (or rather multiple times). Not really an ISY issue, but perhaps an Insteon protocol issue with IOLincs because they have multiple nodes (Sensor and Relay) with the same address. -Seth

I also noticed the large negative values. I'm not an expert on these types of watering algorithms, but it doesn't seem like the outcome of the change is ideal for keeping lawns watered on a somewhat regular basis. Could users that were having problems before use the new 24 hour rain forecast data to help with overwatering? I know I am using it to prevent irrigation if more than a quarter inch is expected in the next 24 hours.

IndyMike, Thanks for all the info. Very helpful. You are right, we have had a wetter than usual summer and I haven't needed to water much. Grass looks good, so I can't complain too much. I'm specifically talking about the periods where we have gone a few days with no rain in the area. I'll check the Irrigation required one evening, and then check it again the next day, and sometimes it is exactly the same. In the instances where normally a new day would have triggered going over my threshold (I set the limit set at 0.5in vs. 0.6in), I have had to manually run the program to keep it on track. I don't remember all of the settings I have for the module, I'll have to check later. Other things: I am running the most recent ISY firmware I have bermuda grass, cut fairly long (second highest setting on push mower) I imagine the stations reportings are fairly accurate, although we do get very isolated storms in the summer I have noticed another inconsistency with KHSV in that it randomly reports light data, but most of the time does not Again, my grass looks good for the most part, and I believe I've had to run the sprinkler cycle 10 or fewer times this year so I think my settings are good. It just seems like the midnight update doesn't happen some of the time. I'll have to do a better job of logging what is happening so I can have more concrete data. Any suggestions on how to easily record daily values in a spreadsheet type format?

I have been having constant issues this summer with either WeatherBug or the ET module algorithm. Half of the times I check the Irrigation required value, it doesn't change from day to day. I end up having to manually run my irrigation program which defeats the purpose of having the module. The value does go up, eventually, but with temperatures around 90 and no rain, Irrigation Required should definitely be going up every day. Has anyone else experienced this? When is this value supposed to be updated? Midnight? FYI, I am at 35756 and have been using KHSV at the airport, assuming that to be the most reliable data. It just gets frustrating knowing that at this point in summer the sprinklers should be going off like clockwork every 3-4 days, but I end up having to do it myself. I'm not sure if this is related to the recent WeatherBug outages, because this issue has been going on all season...

It's nice to see that I wasn't the only one with this issue. Though I wouldn't wish the frustration on anyone, it helps to see that it is not unique to my setup. This definitely seems like an issue that Smart Labs should address with the mesh protocol on the PLM. In the meantime, any word on the priority for the BugID#58 workaround? Hopefully it'll move up the list with more and more people noticing the problem. Haven't noticed any issues since I disabled Query All, but I'd still like to get back to the "nominal" configuration at some point. -Seth

I recognize you may be looking for a solution that doesn't require a radio...but if you have a Midland weather radio, you can connect the strobe output to the sensor on an IOLinc. Works great, in my case I have it so that it flashes the lights in the bedroom if a warning goes off. Some benefits of the weather radio are reliability (does not rely on internet connection) and you may get the notifications a little quicker. -Seth

Just wanted to add that I did something very similar to you, but I added one more feature that I use a lot: "Fast Off" (if keypad is already on) turns on the remaining lights in that scene without having to turn anything off first. It's a little counter-intuitive but it works. The keypad light blinks off and then comes back on since there are lights on. I'm not sure if this would be useful in your situation, but thought I would let people know it was possible. You do have to give up the default Fast Off behavior though, but I'm fine with that.

See my edit as well I'll check the firmware version tonight. Thanks for all your help. I think I'll disable the Query All until #58 is resolved. -Seth

Ok, I see what you're saying. I just remembered seeing this this morning and figured it was differentiating the Sensor and the Relay in all the messages. Thu 02/28/2013 07:16:51 AM : [ 1F C4 AE 1] ST 255 Thu 02/28/2013 07:16:52 AM : [ 1F C4 AE 2] ST 0 So it seems there is a legitimate problem here, in that the PLM should not be passing these dupe messages on to the ISY. That seems like basic mesh networking. The messages bounce around from device to device potentially reaching the PLM at multiple times and at different times. The PLM only needs one of them and should ignore the others. Aside from that, the issue in ISY is that two distinct services (the Relay and the Sensor) have the same identifier, and only differentiate from each other by time, ie query one, get response, query the next, get response. If this delicate balance gets disrupted, the ISY no longer knows what's what. -Seth Edit: I think Bug ID#58 should resolve the problem. Just query the physical device once, makes sense to me. Not sure if maybe there might be a better way to differentiate the two nodes in ISY. I guess it can only work with the messages it is given though. Where should the duplicate message issue be raised? Smarthome? Maybe they could revisit how they differentiate the two nodes in the Insteon protocol?

Lee, Interesting! Thanks for your help. So is this not something that could be weeded out with an ISY update? I agree it sounds like a bug in the mesh/insteon protocol, but that may be more difficult to get a solution for. Seems like ISY could be updated to ignore responses from devices that it has already gotten a response from (at least during the query all function). Thoughts? -Seth Edit: Shouldn't ISY know the difference between Sensor and Relay node responses? I thought each was appended with a 1 or 2 respectively.