Javi

Hi @breischaft, have you tried resetting the lock?

As of this release it is not possible, but this is high on the list.

Hi @TechnoV, UD Mobile and Go2ISY favorites function differently. If you long click and release a favorite name without changing position it will allow for editing when released. See attached video showing changing an icon, Using the kitchen lights scene as a folder so light status will be visible/controllable, then adding kitchen appliances into the folder.

Hi @DennisC, As time permits more features will be added, however I do not have time frames.

Hi @carealtor, Have you submitted an issue? We had a few major bugs with the first release to testers. ISY's without the Z-Wave feature were all affected. It's now very obvious we had no testers without the Z-Wave feature in alpha. Also a few node servers were causing issues, the app is built so node server DEVs can sync and find errors with their node server files before released to users. With this in mind a few node server errors may be presented to the user if they have not been fixed. I'm awaiting feedback from some users who reported issues, most who have responded have reported their issue as resolved by version 0.29. Please submit issues here: https://github.com/UniversalDevicesInc/UD-Mobile-Android Thanks

Hi @vbphil, The minimum sdk supported is 23 (Android 6.0) released in 2015.

Hi @jfai, Thanks for testing. You are correct that the scenes On and Fast On perform the same function. The ISY does not have an Status Controls for scenes. Status to percentage is executed on each device in app and not the scene. I see you have already opened an Issue so will update there. Thanks to everyone for testing!

Working on my end

The battery voltage program is woking over here. I did reboot my ISY just in case. Thanks!

Maybe the above is not true as when the prec of the variable is set to match the prec of the value it will now work as desired

@Jimbo , I think you are on to something. This appears to be the behavior in other nodeServers as well as the following will always be true also. NodeDef <st id="GV16" editor="UV"/> Editor <editor id="UV"> <range uom="71" min="0" max="15" prec="1"/> </editor> Variable Test - [ID 0084][Parent 000F] If 'WeatherBit Weather' UV Index is not '$Int_test UV Index' Then Set 'Devices / Basement / Basement Computer Room Lights' Beep $Int_test = 'WeatherBit Weather' UV Index UV Index Else - No Actions - (To add one, press 'Action')

The value is numerical but raw. I believe "a.bcd" would be equal to "abcd". That said it appears you are correct that the voltage does not update its value to a variable so there may be an issue with the nodeServer or this may not be a comparable type. Maybe @Jimbo will know. "Battery level" appears to work so this may be a work around until the Voltage issue can be resolved. Jimbo, is it possible that this does not work because there is no "prec" declared in the Editor?

@briantreese are you using the url to isy? Also be sure the username an password are not wrapped with a new line char, local connection to the ISY will accept requests with some mistakes but the portal will not.

Thanks! I have spent too much time on this issue, funny how my.isy.io worked but when adding the isyKey it would fail. The malformed /reportURL must have been a copy paste error. Fixing the SOAPAction worked! Passing the isyKey in the Header also works.

@bmercier I am running into a couple of problems. I tried to use HttpURLConnection but the line "Post reuse HTTP/1.1" in the header before the first <Event>...</Event> will throw an exception so I guess I have to stick with SSLSocketFactory (or SocketFactory for local) for the raw output. So my question is, Can the URL to ISY be placed in the request header? POST /isy/url_to_isy/services HTTP/1.1 Host: my.isy.io Content-Type: text/xml; charset=utf-8 Authorization: Basic base64UsernamePassword Content-Length: 192 SOAPAction: urn:udi-com:device:X_Insteon_Lighting_Service:1#Subscribe <s:Envelope><s:Body><u:Subscribe xmlns:u='urn:udi-com:service:X_Insteon_Lighting_Service:1'><reportURL>REUSE_SOCKET</reportURL<duration>infinite</duration></u:Subscribe></s:Body></s:Envelope> Making a request with the header/envelope above will return either " HTTP/1.1 500 Internal Server Error" "Invalid response header received from ISY" on the first request, then "HTTP/1.1 817 unknown" "<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Body><UDIDefaultResponse><status>817</status><info>n/a</info></UDIDefaultResponse></s:Body></s:Envelope>" on subsequent requests. It appears that 817 is listed as "You are already subscribed and there's no need to subscribe again" in the docs.

Thanks @bmercier, I am short of time today but now that I know it is on my side (again) I will try to find a fix in my code. This is for a a native android app (Java) and I was going off my my logs which did not show the actual socket request. Upon looking at my request the socket was using the host (url.getHost) which removed the endpoint. I am using the SSLSocketFactory Library so I may have to use a different library as it appears this only accepts the host and not an endpoint. Thanks again for your time! Javier

I just go around to installing multiple ISY on my portal account and have run into a problem. It appears that no matter which "URL to ISY" I use the (SOAP) socket will always connect to "My preferred ISY". This is not an issue with REST. If I delete "My preferred ISY" i get a Code 400 "Preferred ISY not set on user profile". How can we direct a socket connection to a specific ISY?

Thanks for your time and my apologies for not catching something so simple before posting. It was an error on my side, my app was adding the port to the wrong location (...isy.io/isy/XXXX:PORT instead of my.isy.io:PORT). I guess I have only used local connection for the past month.

Thanks, it appears that adding the port after the URL is causing the error. Was this changed? Edit: Sorry, it appears I made this change adding the port about a month ago. Not sure why it only presented itself now.

@bmercier maybe I am missing something, can you be more specific? This error appears to have started today. The indicator is Green, I am (and have been) using the credentials used for the Portal. Not sure why the SOAP Socket would work with this URL/credentials and REST would fail.

Hi @bmercier, The credentials are valid and the Socket is working however REST commands are failing with the 423 error. This can be replicated in the (Chrome) browser also. https://my.isy.io/isy/XXXXXX:443/rest/nodes/22 89 3A 1/cmd/DOF Where XXXXX is URL to ISY Returns "Requested ISY not found in the user's domain"

@Michel Kohanim I have a report of the Portal not accepting HTTP GET Rest requests and have verified I can also not make the requests Error Code: 423 Response: Requested ISY not found in the user's domain

All is good here also. Although it would be nice to know what causes this error as this is the second day in the last month where I have encountered this error code.

Ok not just me. I have had this error all day but it has not resolved. Rest working, but socket returns the following Code 404 Error contacting sub.server:ETIMEOUT @Michel Kohanim

How are you connecting to the ISY? I am having errors with the portal socket connect today. Came here to see if it is just me