Jump to content

wrj0

Members
  • Posts

    381
  • Joined

  • Last visited

Everything posted by wrj0

  1. I’m having trouble implementing a Network Resource based on a curl command and would appreciate some help. With curl installed, the following works from a command line, immediately returning an appropriate response from the (InControl Pro) application on port 1178: curl -X PUT -H "Content-Type:application/json;charset=utf-8" -d "{\"password\":\"\"}" http://192.168.3.105:1178/zwave/getScenes But, my attempts to translate the above into an ISY Network Resource fail, returning “Error: Request Failed,†and “N/A†in the ISY Resource Response window. Error Log shows: [TCP-Conn] -1/-140002, Net Module Rule: 116 Bumping the Timeout to 9000 returns the same result. I’ve tried various permutations of PUT, POST, modes, Encode URL, {} and "", all with the same result. Suggestions on what to try next will be greatly appreciated. Thanks.
  2. Hey apostolakisl, Thanks for another one of your brilliantly simple solutions. After seeing your timed light program method, I had another one of those "man...that's a slick way to do it" moments. Keep 'em coming.
  3. I have to agree with Xanthos' observations; my T1800 Venstar adapter has been working great for the past year. The initial version installed did have some communication problems, but after providing some diagnostic information to Smarthome, they provided a replacement adapter (rev 2.4 "FWD5") that has been working flawlessly. It manages temperatures and modes several times a day without any problems at all.
  4. Plau, Launch the ISY Dashboard and login, then under settings (the wrench icon), you should see the Verify checkbox under the section "HTTPS Server Settings."
  5. wrj0

    Programing trouble

    I have also had positive experiences dealing with Smarthome. Recently, a 2413S dual-band PLM failed, two months inside the warranty. (My luck is normally on the other side of the warranty calendar!) With a single call to Smarthome describing the problem (suddenly, all device querys returned ERR), they provided a pre-paid return shipping label, and a week later I received a notice that the replacement device had been shipped. No complaints here.
  6. Weatherbug seems to have their Backyard server back on line. WB data for my station has been available for the past few hours and is now being pulled successfully by the ISY.
  7. They (sort of) did. http://backyard.weatherbug.com/notes/Backyard_Station_Outage_Again
  8. WB status update indicates backyard stations are still out. My station is publishing, just can't pull the data from WB. http://backyard.weatherbug.com/
  9. My station also reports raw data, but for the past few days has been unavailable on the backyard station list. It seems all backyard stations stations are still unavailable on the site below. http://weather.weatherbug.com/USA-weather.html
  10. Excellent! Thanks Michel.
  11. Having a similar problem the past few days. Opened a ticket with WeatherBug and just received the following response: "We're having another outage on Backyard Stations. Our teams are working on them as we speak" Perhaps a good time to again request native ISY support for Davis Weather stations. Sure would be nice to read that data directly from the LAN, rather than having to depend on WB.
  12. Michel, There were several beta releases between the versions that I tested. I'm not sure exactly what change(s) corrected my routing problem, but will poke around in the dd-wrt forum to see if something stands out and will post back if something seems applicable.
  13. After a lot of reading about iptables, setting up forwarding rules and logs to track traffic, and putting way more time into Wireshark and WallWatcher than I should have this week, I could not discover anything wrong with the iptables commands or the router configuration. So, after resetting and rebuilding the router (twice), I finally tried flashing it with one of the new beta releases of dd-wrt. Bingo - the ISY resource that has given so much grief for the past week is once again working. (the ddwrt wiki-recommended build 19342 was problematic; build 21061 seems to be working fine) Thanks again to Michel for reviewing my Wireshark capture and offering suggestions.
  14. Sure, Michel. Thanks. Will send the info via a PM. Sorry for the delayed reply; changed to a new cable modem yesterday and it took almost a full day for the ISP to get it properly provisioned. (Tier 1 support said to wait 72 hours, check, then call back. Tier 3 this morning got it provisioned in less than 15 minutes.)
  15. Hi Michel, ISY-994/IR Pro is running v4.0.2
  16. Well…I’ve managed to break the Internet Test network resource again. Argh! This time, it’s my own doing – decided to upgrade my old router and install a Linksys E2500 with DD-WRT firmware. With the new router in place, the ISY-994 works fine, except it cannot set a variable using Xanthos’ Network Resource technique described previously in this thread. DD-WRT has more extensive configuration capability than that of the old router (as well as my ability!), so, I’m hoping someone can help with the configuration in the new router. With the old router in place, the network resource works fine, so the ISY certificates seem to be OK. ISY DNS is set to the ISP’s recommended DNS server; nslookup returns that URL. With the new router in place (setup where possible to match the old router’s configuration), Network Resource returns: “Error: Request failed.†and "N/A" in the Resource Response window. ISY Event Viewer, Level 3 shows: “Network Resource: Failed connecting to my.dyndns.org†Using REST to set the same variable works fine from an outside PC, so port forwarding seems to be OK (setup same as in the old router). ISY NTP and outbound email functions work fine with the new router in place. Other Network Resource functions (e.g. prowl notifications) also work properly. Remote access to the ISY works fine from an outside web connection and from MobiLinc. Except for this one Network Resource, everything else seems to be working fine. I’ve tried changing several parameters in the new router, including turning off SPI and putting the ISY into a DMZ to see if there was a port problem – same result. The new router is running firmware: DD-WRT v24-sp2 (06/08/12) mini - build 19342 DNSMasq is disabled. Running the Network Resource and capturing the router log returns: root@DD-WRT:~# cat /var/log/messages | grep 30.100 Mar 22 10:55:06 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=vlan2 SRC=192.168.30.100 DST=54.234.34.59 LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=27770 PROTO=TCP SPT=34720 DPT=48201 SEQ=4073191765 ACK=2888464856 WINDOW=4256 RES=0x00 ACK URGP=0 Mar 22 10:56:08 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=vlan2 SRC=192.168.30.100 DST=24.25.5.61 LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=27825 PROTO=UDP SPT=53 DPT=53 LEN=40 Mar 22 10:56:08 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=br0 SRC=192.168.30.100 DST=192.168.30.100 LEN=48 TOS=0x00 PREC=0x00 TTL=59 ID=27826 PROTO=TCP SPT=34743 DPT=443 SEQ=556354701 ACK=0 WINDOW=4644 RES=0x00 SYN URGP=0 OPT (0402010101010100) Mar 22 10:56:10 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=br0 SRC=192.168.30.100 DST=192.168.30.100 LEN=48 TOS=0x00 PREC=0x00 TTL=59 ID=27828 PROTO=TCP SPT=34743 DPT=443 SEQ=556354701 ACK=0 WINDOW=4644 RES=0x00 SYN URGP=0 OPT (0402010101010100) Where, vlan2 is the router’s WAN connection to the cable modem, br0 is a bridge from eth1 to vlan1 (the LAN ports on the router), 192.168.30.100 is the ISY address, and 24.25.5.61 is my ISP’s DNS server. So, after lots of head scratching and changing lots of router settings, I just can’t seem to find what’s wrong with the new router configuration to support this Network Resource in the ISY. It seems there’s something going on in the new router that prevents the ISY from sending the REST command and then looking for it’s own response. Perhaps an appropriate entry in the router’s iptables would do the job, but I’m at a loss and could use some help from the linux guru’s here. Wonder if anyone else is using DD-WRT and has this Network Resource working? Any suggestions will be greatly appreciated. Thanks.
  17. Thanks, Xathros. Is the Nexia version required? I understood from this post that it was not.
  18. Hi, For someone considering installation of Z-Wave deadbolts, what Z-Wave devices or starter kits are recommended? I have several Insteon devices integrated with an ISY994i/IR-Pro, but currently don't have any Z-Wave devices. What should be installed to support reliable operation of Z-Wave deadbolts to be managed by the ISY994? Advice from those who have already been down this path will be greatly appreciated. Thanks.
  19. Some of us have powered our ISY through an Elk relay just for these rare events. A quick initiation of an Elk rule to force an output to momentarily interrupt power to the ISY allows the needed remote reset. Helps with the WAF, especially when traveling away from home.
  20. With some outstanding support from Michel (does he provide anything else?), my Internet Test Network Resource is finally working again. Something was amiss with my certificates, and my attempts to find a working solution failed until Michel got involved. In short, his recommendations were the following: I had previously tried various combinations of Strengths for both Client and Server, but per Michel's suggestion, set both Server and Client Strengths to the same level (Medium or better Client setting is needed for Elk support). Additionally, Server Protocol was set to TLS 1.2, and Client Protocol to TLS 1.0. There remained an issue with one of the Self Signed certificates, likely the Client certificate as it seemed it was not being validated by the ISY Server. So Michel recommended: I may not have been diligent at performing step 1. during my testing. So, Michel's instructions were followed explicitly, and after a couple of reboots the Network Resource is once again working properly, able to set or clear a variable. Here's a BIG THANK YOU to Michel for revolving this issue and my frustration. Thanks also to Xanthros and TJF1960 for their input and keeping me going on this.
  21. Will do, Michel. Thanks.
  22. Michel, Many thanks for investigating and addressing this problem. Your support for the ISY products is truly outstanding. Unfortunately, after upgrading to 3.3.9, I did not experience the same success as TJF1960 and continue to have the same results as before, both before and after creating new self-signed server and client certificates. Since others have been successful, I'll continue to work on the certificates to see if I can find a configuration that will work for me. TJF1960: Glad to hear its working for you - gives me a glimmer of hope that I'll eventually find the cause of my problem.
  23. SSL verify remains disabled for both Server and Client in the 994 dashboard. Have to keep it disabled for prowl notifications to work. Thanks for the suggestion.
  24. Thanks, Michel. I've bumped timeout to 9000 with the same result. At some point prior to my upgrading to the 994 and to rev 3.3.8, this was working. Also, this command still works fine from a browser: "https://my.dyndns.org:443/rest/vars/set/1/99/1" (actual domain name modified for this post) Wouldn't that imply a proper response from the dyndns server? If so, I'm curious what else may have changed. It seems like both TJF1960 and I started having a similar issue sometime after rev 3.2.6; please refer to his post above in this thread.
  25. Thanks again, Michel. Here's the result of the test and Error Log, after clearing the Error Log. Running Test on the Network Resources entry returns a pop up window: "Error: Request Failed." Resource Window displays: "N/A" Event Viewer, Level 3 returns: Net-Resource: Failed connecting to my.dyndns.org Error Log shows: User: System Code: -170001 Message: [TCP-Conn] -3/-140002, Net Module Rule: 73 (The Network Resource being tested is ID: 73) I'll try to play with Wireshark when I get some additional time.
×
×
  • Create New...