dpeterson4ca

hmmm... guess the question I would pose is, "is it a Z-Wave dongle we have in the future of the 994-Z-Wave product or an integrated design?"... likely, the dongle will satisfy all near-term functionality, but can UDI give some insight into how long this "dongle" configuration might live...? Maybe just looking too far ahead considering this is still an alpha implementation...

...well, guess that's the curse of progress... the previously retired 26 will now have a new additon to the garage "antique e-display"... and both of my houses will now have 994's... will the 994"s be upgradeable to Z-Wave in the future or will this also require a new box...? Thanks.

What is the best way to take an ISY-99 and PLM from loaded with pgms and links from a previous installation and clear it out for a completely new install? Factory resets obviously will do the trick, but I would rather not reload all the ISY pgm updates if there is another way. thanks...

Thanks for the heads-up, Michel!... as soon as I get my hands on a unit, I will report back as I have several First Alert ONELINK devices I am anxious to link to...

Excellent, thanks!... looking forward to seeing how this integrates with the detectors and pgming...

Just received an email from Smarthome about a new device called a "Smoke Bridge" (model #2982-222). http://www.smarthome.com/2982-222/INSTE ... =HML13RA18 Seems it is an Insteon conduit for the line of First Alert ONELINK detectors. Is this something the ISY will support soon? Thx.

The pre-loading of 2.6.0 has allowed a successful upgrade on my ISY-26 from .14 to .15. Also had a successful upgrade on my ISY-99i. Thanks, Dave

Well, this is very weird... VE does display 2.6.14, but the upgrade obviously got loaded, rebooted and came up successfully. Is there a possiblity that the link to the new f-w is pointing to the .14 version?

Just upgraded one of my 2 ISY units which happens to be the ISY-26. I observed a successful upgrade and reboot, HOWEVER, in the "ABOUT" drop down, the version remains 2.6.14. I think this is a bug as the code is indeed different. (I actually verified the "...display device links... " COMPARE bug is fixed.) I don't know if this is the same for the ISY-99i, but will do that upgrade later today and report. Dave

Repurposing my old ISY-26 to control a new property and have bought a new ISY-99i PRO to replace it at my home. I'm assuming the changeover to the ISY-99i PRO is as "easy???" as backing up my ISY-26 configurations and programs, then physically swapping the units, upgrading the FW on my ISY-99i to the same as the ISY-26 (2.6.4), configuring the network values and restoring the config and programs.... Am i missing something? Thanks for any help you can provide! Dave

Michel, Unfortunately, no further suggestions at this time, but I will continue to snoop around and post if I discover any more detail. Thanks so much for you support and keep up the great work! I'm just having a BLAST with my ISY. Cheers! Dave

Michel, More experimenting with BB browser configuration changes and I found another combination that makes a difference. The browser configuration item "Content Mode" has 3 choices, HTML only, WML only, WML & HTML. With Content Mode set at HTML only, disabling JavaScript allowed my BB to successfully communicate with the ISY. Enabled JavaScript caused comm errors. With Content Mode set at WML & HTML, the state of JavaScript did not matter, the communications were SUCCESSFUL whether enabled or disabled. Do you use any WML in your scripts?... still confusing, but I feel I am getting somewhere. Cheers! Dave

Michel, I do not get the Admin console header in either case, which seems to indicate my BB is recognized as a mobile device. Which leaves the bigger question of why enable/disable JavaScript has anything to do with the problem... hmmm... Dave

Michel, Ah, understand now. However, if the HTTP request did not indicate to your code you were talking to a mobile device, you would probably send not only the headers "DEVICES, SCENES, PROGRAMS" but probably "ADMINISTRATIVE CONSOLE", which I do not get. Does this sound right? I'm sure there's a root cause here somewhere. Thanks for the continuing thought cycles... Cheers! Dave

Michel, I'm not familiar with the term "user agent". Is this something you can provide more detail on? where can I find this value? Thanks, Dave

Ron, Interesting result, just the opposite of what worked for me and my 8320/Curve (T-Mobile). I verified again this morning enabling "Support JavaScript" caused comm error problems. Maybe service provider dependent? what a pain... Cheers! Dave

Michael, Here is my BB browser config: Browser Configuration Browser: BlackBerry Browser Support JavaScript DISABLED Prompt to enable JavaScript ENABLED Support HTML Tables ENABLED Use Foreground and Background Colors ENABLED Use Background Images ENABLED Support Embedded Media ENABLED Support Style Sheets ENABLED Style Sheets Media Type: Screen Show images: On WML & HTML pages Emulation mode: Microsoft IE Content mode: HTML only Start page: Bookmarks Page Home page address: http://mobile.blackberry.com General Properties Default Browser: BlackBerry Browser Enable JavScript Location support ENABLED Prompt before: Closing browser on escape DISABLED Closing modified pages ENABLED Running WML scripts DISABLED Hope this helps. Dave

Good news! After some experimention I have discovered a BB Browser Configuration setting which eliminates the "comm errors" I experienced above and now all mobile commands and HTML functions execute successfully between my 8320 and ISY-26. Changing the BB Browser configuration of "Support JavaScript" to DISABLE (not checked) allows all actions to work. Enabling and disabling this configuration verified this result. (...don't ask why, I don't have a clue...) Can't imagine this is unique to me and hope this can help out other BB users. Cheers! I'm a happy man today as I am finally "mobile"... Dave

Michael, It would be helpful to know exactly when you are seeing these errors occur. For example, is it after you access the HTTPS://ISY, select DEVICES/SCENES/PROGRAMS, send your username/password, select a controller/scene, send a command, send another command immediately after the 1st... I have only seen the comm error at very specific steps in this process (as mentioned above). I am curious whether you are seeing them at the exact same time or are your errors happening at different points. Thanks, Dave

Michael, to answer your question, no I did not change anything on my BB. However, Wednesday was the first time I used the BB with my ISY-26. I had weeks of problems trying to get HTTPS to work, but finally got those issues resolved. Dave

I am running BB v4.2.2.180 on my 8320. The unique problem here is the response to the selection of a "command". Selecting and executing a command is the only event which causes the "comm error" on my BB. Dave

Michel, Thanks for your attention to these issues... I'll keep plugging away to see if I can find a configuration change or workaround which may improve my results. Meanwhile maybe a BB user will come forward with another view... Cheers! Dave

Michel, 2x the CWT timeout (20Kms HTTPS/2Kms HTTP) and the results are exactly the same. Interesting the BB browser error message does not take 20s to appear, it happens in 5-7s. Maybe the key is in the error text itself: "A communication failure occurred with the selected Mobile Data Service. The server may be busy, please try again later. If the problem persists, contact your administrator. (OK)" This actually may not be a timeout message, but certainly a comm error. Retries of the command are consistently unsuccessful. The result however is very consistent when going through these steps and only happens when tyring to execute a command. Patterns: DEVICES>Controller>1st cmd>2nd cmd [fail]; SCENES>Scene>cmd [fail]. I have not seen this error with any other non-command selection. PROGRAMS seems to work fine. Are there any other BB users who have seen these issues? Dave

Michel, I'm not quite sure I understand your response, but let me clarify my observations/actions and follow-up with a question. Time between sending commands is well over 30s. Fact is the BB browser process to send the command and receive a response ("requesting-loading" cycle) takes 7-15s typically (this is EDGE not 3G). Now with that being said, could this timing be what you are referencing to as the "HTTPS" timeout? if the BB takes a long time to send a command... Finally, the complete inop of the Scene commands has me troubled. Not sure why there would be a difference between Device commands and Scene commands from the HTML interface... I could actually deal with the "cmd-refresh-cmd" cycle, but I really would like the Scene commands to work. Appreciate any additional insight you can offer here. Thanks! Dave

Michel, Tried sending some commands after selecting SCENES and every command I tried with several scenes failed with the "comm timeout". No scene command was successful. I verified the DEVICES has the same initial problem before I started during one session, then closed the browser, went directly to SCENES, tried sending commands again and saw same timeouts. Did find an interesting result after playing around with the DEVICES issue mentioned above. If, after you have sent the 1st device command successfully, you select "Refresh" on that page, the 2nd command works! Turns out the command sequence on any device page "cmd-Refresh-cmd-Refresh-cmd-..." always works, but the 2nd command of 2 sent back-to-back never works. BTW, this is the first time I've spent any significant time with the mobile access, as I initially had trouble getting my BB to work with my https site. It's working now and I'm seeing these issues. Cheers! Dave