mbking

This issue is fixed with the ISY on Polisy v5.0.4_13 update.

Any one else having problems saving state variables? I can enter them and then use them in a program, but if I exit the Admin Console and then log back in, they're gone. Mark

Will do! Sent from my iPhone using Tapatalk

@Javi, As far as I know, yes. I had one update available last night which upgraded ISY from 5.0.4-6 to 5.0.4-8. FreeBSD Polisy 13.0-RELEASE-p3.

@Javi, The issue may be related to converting from 24 hour format to 12 hour format. All 3 program times have incorrect values and they are initially incorrect. My times are shown in 12 hour format with exceptions. While looking at my test program in UD Mobile, I changed to the start time in the Admin Console and the Next Scheduled Time immediately change to the new time, but was off by 5 hours. It was in 12 hour format. When the program started, the Last Run Time and Last Finish Time changed to 24 hour format and were correct. I let the program finish and the Last Run Time and Last Finish Time were as expected and still in 24 hour format. But when I backed out of the program screen and went back in, the times had changed to 12 hour format and were 5 hours off. Hope this helps. Mark

@Javi, I recently connected ISY/Polisy to UD Mobile and I notice the program event times are off by 5 hours. For example, a program start time that should be 11pm is actually shown as 6pm. The times are correct in the Admin Console. My time zone is set to Austin, TX. UD Mobile displays the correct times for my other system, an ISY-994i. Sent from my iPhone using Tapatalk

@Javi, I think the Favorites Command Type could work to create a nice toggle with a custom icon and name. I think I would need to use a node server like Push or Notifications to get the state labels I would need as those are unlikely to be available in any of the node servers I have installed. Both of those node servers allows the user to configure a list of messages which could include the labels I need. I could then associate them with the correct state in the Command Type favorite. On paper, it seems like it could work. I'll look forward to trying it out when that feature is added to the iOS app. Mark

@Javi, Thanks for the quick replay. I'll need to think this one through to see how I might implement the Command Type to produce the interface I'm looking for. Looks possible. Mark

@Javi, There is one feature I'd like to see in UD Mobile before I can fully switch to using it exclusively. I need to have more control over what happens when I toggle a program. In some cases, I use programs to toggle a state I want to make available to the user. That means I need a favorite for a program that allows me to toggle True/False or Run Then/Run Else. The current program toggle doesn't give me that option. In addition, it would be nice to rename each toggle state as required. For example, TV/Movie lighting or Home/Away. This allows me to make an interface that is intuitive for users who don't really understand the automation system and don't want to; like my wife. ? The more intuitive, the more likely she will use it and allow me to expand automation around the house. Any chance this could be added? Also, are you planning to implement iOS push notifications? I use these extensively. I see that there is a Notification node server that could fulfill that need, but I was planning to use it only for emergency notifications. Just curious what the future plans were. The application is really great and I appreciate the work you've been putting into it. Thanks, Mark

@gviliunas, I had a similar issue and Michel had me run the following command: sudo pkg upgrade -f FreeBSD-kernel-polisy (don’t forget the -f) I believe this forces an update of all FreeBSD files. That made it possible for ISY Finder to see my ISY on Polisy and everything is running fine. I still get the same "pkg not found" message, but Michel indicated that will eventually go away when that package is actually updated. Hope this helps. Mark

@mmb, I did the same thing and that seems to have eliminated the X10 messages in the log. The switch I'm using for testing is a new switch from Smarthome, but I've learned that items from Smarthome are not always "factory fresh". I was in a hurry to try out the new ISY on Polisy and skipped the factory reset before installing the test switch. I recommend everyone "Factory Reset" the Insteon devices they buy. Mark

@Michel Kohanim, Update: If I use Admin Console(LAN), the log in the Admin Console has the correct event times. Mark

@Michel Kohanim, I'm retrieving the log from the Admin Console and using Admin Console(Cloud). Here's my About:

@Michel Kohanim, The only remaining issue I have is an incorrect time stamp in the ISY Log file. All time stamps, including new ones, are: Mon 1900/01/01 12:00:00 AM I did a Reboot from the Configuration tab, but this did not fix the time stamp issue. Mark

@Michel Kohanim, The IP address in the Configuration tab is correct and I checked the UDX service and it's running. When I first installed ISY on Polisy, the day, date, and time in the upper left corner of the Admin Console appeared to be correct. The only issue I saw was that program events fired about 20 seconds ahead of what was programmed based on the displayed time. The program summary, though, indicated the event fired at the correct time. I reboot of Polisy corrected that problem. But the time zone was incorrect. It displayed USA, CA, Los Angelos instead of USA, TX, Austin which is what's stored in the Polisy settings. I decided to change the time zone in Polisy to San Antonio, TX and then back to Austin. That did not fix the issue in the Admin Console. But they are actually the same (-6) zone. So I then changed the time zone to a city with a (-7) zone and then back to Austin. This fixed the problem in the Admin Console. I now have the correct time zone displayed as well as correct sunrise and sunset. Not sure if this is related to the issue in the log, but I thought I'd mention it since it seems to be related to communication with UDX. If there are any tests or commands you'd like for me to run, I'll be happy to. Even if I have to start over installing ISY, I can. Just let me know. My configuration is small. Thanks, Mark

@mmb, Yes, I rebooted the Polisy box and for good measure, restarted the ISY service. No luck yet. It's a minor issue right now, the ISY service is working. I must have an issue with the installation somewhere. Maybe a future update will fix whatever irregularity I have. Mark

@Michel Kohanim, I've been clearing the log before initiating a few events to see if the date and time is correct and it is still giving me the same results. To be clear, I'm looking at the Log file under Tools in the Admin Console for the ISY on Polisy. I took a quick look at the Error Log and it seems to have the correct date and time. I've verified that I have Polisy v5.0.4 firmware per the display under Help->About in the Admin Console. While experimenting with this issue this afternoon, I noticed that while the date and time were correct in the Admin Console display, my time zone was not. The Admin Console showed Los Angeles and my Polisy setting is Austin, TX. The sunrise and sunset where off as well. I went into the Polisy Console and changed my location to San Antonio, TX and then back again to Austin, TX. I then did a "sudo service isy restart" and now the location and sunrise and sunset are correct in the Admin Console for ISY on Polisy. I have the one dimmer controlled by a single program and that program fires at the correct times in the If statement. It's just the time stamps in the log file that I'm having issues with. Anything else I should try to fix the time stamps? Mark

Yes, I’m on 5.0.4. Sent from my iPhone using Tapatalk

I'm seeing some unexpected behavior in the ISY on Polisy log file as well. Not only am I seeing some X10 activity I don't expect to see, but my time stamps are incorrect. I have one dimmer added with a single program set to turn it on and off. That is working as expected. Not sure why the time stamps are incorrect, though. Times in the Admin Console look OK. I forgot to factory reset the dimmer switch before adding it, so I will do that to see if it eliminates the X10 entries. I've received some items from Smarthome that are not factory reset and this could explain the X10 entries. Any thoughts on the time stamp issue?

Not that this will answer the question as to whether Smathome will continue to sell a PLM, but I just got a new serial PLM under warranty, even though the website lists it as Sold Out. It did take several days for them to OK the replacement, but once they did, the new one shipped out immediately. I suppose Smarthome has a supply in reserve. The version is 2.6. I'm going to hold onto the old one and replace all the caps. It has started losing its link table and for me, that's been the first sign of impending failure.

Update was successful. I did not get all the beeping patterns that others have reported, but everything is up-to-date and running normally. Thanks to @Michel Kohanim and the rest of the UDI team for such a smooth update process.

@Michel Kohanim, thanks for getting back on this. Been held up with other priorities, so I haven't tried it yet. I did have a question, though. If this process updates your existing node servers to use Python 3.8, do you need to avoid adding or updating existing node servers until all node servers in the store are updated to use Python 3.8?

Any word on whether it's safe to update Polisy now after issues with OS upgrade to 13?

I'm using the ELK node server in Polisy and it works really well in UD Mobile.

@Javi, couldn't get the above to work. I think I can switch between Mobilinc Connect and ISY Portal within the ISY with relative ease, but we'll see. What's the best way to request feature enhancements in UD Mobile? There are a few things I can do in Mobilinc X that I can't do in UD Mobile, but UD Mobile has the edge in it's implementation of the node servers.