Jump to content

When will PolISY be shipped?


Blackbird

Recommended Posts

The first batch went to what they call the "geeks", those that identify bugs etc.  There have been a number of issues that have been identified and I trust that UDI is working on addressing these issues, so that the non-geeks (like myself) can receive a product that will work on-the-go.

I currently have Polyglot working fine on a RPi, so I prefer to wait and get a well working Polisy.

Link to comment
  • 4 weeks later...
8 minutes ago, Michel Kohanim said:

Hello all,

Doing final testing. Definitely by the end of the week if not sooner. For those who already have Polisy and want to give system configuration UI a try, please send an email to support@Universal-devices.com with the subject UDX test.

With kind regards,
Michel

E-mail sent...

Link to comment
2 hours ago, Michel Kohanim said:

Hello all,

Doing final testing. Definitely by the end of the week if not sooner. For those who already have Polisy and want to give system configuration UI a try, please send an email to support@Universal-devices.com with the subject UDX test.

With kind regards,
Michel

Thanks Michel.

I am in for sure but "time of trial" will be based on what this actually means. Can you elaborate, with a rough "data path" description of what and where? 
ISY(polyisy) <----> polyglot(polisy),   ISY------> wife's Christmas present junk box ???

Link to comment
14 minutes ago, larryllix said:

Thanks Michell.

I am in for sure but "time of trial" will be based on what this actually means. Can you elaborate, with a rough "data path" description of what and where? 
ISY(polyisy) <----> polyglot(polisy),   ISY------> wife's Christmas present junk box ???

I received an email today stating that "Your Universal Devices pre-order from December 15, 2019 is now available" 

However there is no information when it is being shipped. I was expecting that the shipment would be today 12/17. Please advise,   Order # 43386

Link to comment
16 minutes ago, Tominnh said:

I received an email today stating that "Your Universal Devices pre-order from December 15, 2019 is now available" 

However there is no information when it is being shipped. I was expecting that the shipment would be today 12/17. Please advise,   Order # 43386

See Michel's post from above

Link to comment

Hello everyone,

We found a few last minute bugs most of which have already been fixed. So, although we could not ship today, but we can definitely ship by no later than Friday.

@larryllix, to answer your questions, as you may know, Polisy is a brand new platform, OS, and completely different than ISY. The most important difference between ISY and Polisy is the difference between RTOS and a Unix based system. So, when we started this journey, we had to make sure that the design is a) extensible and modular b) light weight enough so that both ISY and Polyglot can run on the same platform and c) conducive to piece by piece integration and d) modern UI that allows configuration of the hardware and d itself. i.e. we decided against a big bang approach.

Given the history, the tasks were:
1. Deploy our own package repository, build process, and packages. This way, not only Polisy is extensible and modular but also all packages are built and tested exclusively for Polisy
2. Design a modern and secure communication interface for configuring the hardware. We call this UDX which is a light weight and secure service layer to the hardware and OS. UDX currently does network configuration, WiFi configuration, date/time zone configuration, checking for upgrades, upgrading the system, managing the serial ports, GPIO, reset switch, logs/rotations, etc. All this is done through MQTT using certificate authentication (even though they run on the same box). So, the only way anyone can communicate with UDX is to have access to the certificates 
3. Enable the integration of Polyglot UI with UDX through MQTT
4. Migration of ISY:
    a. Extending UDX to include the abstraction layer for ISY
    b. Connecting physical ISY through the abstraction layer so that a modern UI can be hosted on Polisy as a proxy to ISY
    c. Porting/migrating ISY using the abstraction layer and thus removing the physical ISY

So, where are we now?
1. Done
2. Mostly done
3. Done for everything in #2
4a. 85% done. Almost all RTOS high level artifacts, such as Mailbox, Queue, Task, Flag, etc. have already been designed, developed, and tested with test programs
4b. 0% done
4c. 0% done

So, in addition to full fledged Polyglot (minus bluetooth support as it has proven more difficult than anticipated), what you will be testing, and what's being shipped is Polyglot + Polisy configuration in one UI allowing you to configure and manage the system (#2 and #3). And, of course, the beauty is that once deployed, upgrading everything (including Polyglot) will be as easy as clicking a button (no more sudo pkg update && sudo pkg upgrade). Even easier than ISY since Polisy will download, decompress, and install everyting on its own. Once this infrastructure is in place, all our efforts will be spent on 4a, 4b, and 4c.

With kind regards,
Michel

 

Link to comment

@Michel Kohanim,

Hi Michel,

First, thanks for the update on ISY/Polisy. Glad to hear you are progressing with moving all of this forward.

I would like to suggest you add developing a Mobil app to support Polisy/ISY. While it is true Mobilinc is actively being developed and supported across both Apple and Android versions now, there doesn't appear to be support for Node Servers coming soon. As for Agave, development appears to have stopped and support response slowed, with commitment to have Node Server support soon.

Since Node Servers are a big part of UDI's future, access from a Mobil app is important. One example is all of the great weather related Node Servers now available.

Thank you for your consideration.

 

Link to comment
On 12/18/2019 at 3:37 AM, Michel Kohanim said:

Hello everyone,

We found a few last minute bugs most of which have already been fixed. So, although we could not ship today, but we can definitely ship by no later than Friday.

@larryllix, to answer your questions, as you may know, Polisy is a brand new platform, OS, and completely different than ISY. The most important difference between ISY and Polisy is the difference between RTOS and a Unix based system. So, when we started this journey, we had to make sure that the design is a) extensible and modular b) light weight enough so that both ISY and Polyglot can run on the same platform and c) conducive to piece by piece integration and d) modern UI that allows configuration of the hardware and d itself. i.e. we decided against a big bang approach.

Given the history, the tasks were:
1. Deploy our own package repository, build process, and packages. This way, not only Polisy is extensible and modular but also all packages are built and tested exclusively for Polisy
2. Design a modern and secure communication interface for configuring the hardware. We call this UDX which is a light weight and secure service layer to the hardware and OS. UDX currently does network configuration, WiFi configuration, date/time zone configuration, checking for upgrades, upgrading the system, managing the serial ports, GPIO, reset switch, logs/rotations, etc. All this is done through MQTT using certificate authentication (even though they run on the same box). So, the only way anyone can communicate with UDX is to have access to the certificates 
3. Enable the integration of Polyglot UI with UDX through MQTT
4. Migration of ISY:
    a. Extending UDX to include the abstraction layer for ISY
    b. Connecting physical ISY through the abstraction layer so that a modern UI can be hosted on Polisy as a proxy to ISY
    c. Porting/migrating ISY using the abstraction layer and thus removing the physical ISY

So, where are we now?
1. Done
2. Mostly done
3. Done for everything in #2
4a. 85% done. Almost all RTOS high level artifacts, such as Mailbox, Queue, Task, Flag, etc. have already been designed, developed, and tested with test programs
4b. 0% done
4c. 0% done

So, in addition to full fledged Polyglot (minus bluetooth support as it has proven more difficult than anticipated), what you will be testing, and what's being shipped is Polyglot + Polisy configuration in one UI allowing you to configure and manage the system (#2 and #3). And, of course, the beauty is that once deployed, upgrading everything (including Polyglot) will be as easy as clicking a button (no more sudo pkg update && sudo pkg upgrade). Even easier than ISY since Polisy will download, decompress, and install everyting on its own. Once this infrastructure is in place, all our efforts will be spent on 4a, 4b, and 4c.

With kind regards,
Michel

 

I assume that Polisy will come with manual on how to move my Nodeservers from RPi to Polisy ?

Link to comment
2 hours ago, DennisC said:

@Michel Kohanim,

Hi Michel,

First, thanks for the update on ISY/Polisy. Glad to hear you are progressing with moving all of this forward.

I would like to suggest you add developing a Mobil app to support Polisy/ISY. While it is true Mobilinc is actively being developed and supported across both Apple and Android versions now, there doesn't appear to be support for Node Servers coming soon. As for Agave, development appears to have stopped and support response slowed, with commitment to have Node Server support soon.

Since Node Servers are a big part of UDI's future, access from a Mobil app is important. One example is all of the great weather related Node Servers now available.

Thank you for your consideration.

 

The mobile app idea is beating a dead horse. That's far from being on UDIs roadmap. Though not supported by other apps, most likely as nodeservers grow, app makers will include them. 

Wes has stated he is looking into supporting nodeservers directly. While no timeline is given, it would happen much faster through him than UDI as they would need to build from scratch. Wes did state if nodes are read as regular devices then they should work within the current mobilinc X app though it hasn't been tested

Link to comment
@Michel Kohanim,
Hi Michel,
First, thanks for the update on ISY/Polisy. Glad to hear you are progressing with moving all of this forward.
I would like to suggest you add developing a Mobil app to support Polisy/ISY. While it is true Mobilinc is actively being developed and supported across both Apple and Android versions now, there doesn't appear to be support for Node Servers coming soon. As for Agave, development appears to have stopped and support response slowed, with commitment to have Node Server support soon.
Since Node Servers are a big part of UDI's future, access from a Mobil app is important. One example is all of the great weather related Node Servers now available.
Thank you for your consideration.
 

Agree. UDI should absolutely make an app. Let others make apps too but have your own. Could sell a lot more hardware i think if people knew the company was behind an app. I would bet that people who bought Agave are not too happy about it given that it appears that developer has really stepped back from that app. While obviously not UDI’s fault, I imagine that could leave a bad taste in people’s mouth and some may (unfairly) associate some of that with UDI.


Sent from my iPhone using Tapatalk
Link to comment
5 minutes ago, TrojanHorse said:


Agree. UDI should absolutely make an app. Let others make apps too but have your own. Could sell a lot more hardware i think if people knew the company was behind an app. I would bet that people who bought Agave are not too happy about it given that it appears that developer has really stepped back from that app. While obviously not UDI’s fault, I imagine that could leave a bad taste in people’s mouth and some may (unfairly) associate some of that with UDI.


Sent from my iPhone using Tapatalk

I don't agree with the "app business".  Here's why.

I know of 2 major platforms that in the last year have shifted their "direction" to being mobile first.  Both were automation platforms that had remote access and had a way of doing things.  "New Users" all whined for a "mobile app" to be "easy" and because they wanted an "app".....

So one platform catered and developed a basic app for the users.  The users do NOTHING BUT COMPLAIN because the app is basic and because it's not the core business it does not function well all of the time and is just not that good of an app.  Because it's not the core business and they didn't have proper resources (staff) to build a good app now they have a crappy app that people still complain about and they have to shift resources around trying to "appease" these "basic users" and support the app they released.

The second company went so far as to modify the core of their system interface and functionality to make an app that was super "pretty" and gave new users what they are wanting.  The result is that is destroyed the local web UI for real users that want to have flexible administrative control and power to make their system do what it's supposed to do... AUTOMATION.  But hey it looks "Pretty" right?  So now there's a powerful system that's pretty and "easy" but to really do anything takes 100 mouse clicks a and dozens of popup windows and scrolling through hundreds of pages of devices to do anything.. but it's pretty!!!!

Moral is... UDI and these other companies are NOT app developers and unless You and others that really want an app shell out the upfront capital to hire the staff necessary to properly developer a mobile app then I won't want UDI or any other company spending time/resources on a mobile app when there are 3rd party companies already out there doing this and doing it well.  If you want the mobile app to be better... please complain to those companies.  UDI is a automation system NOT a control system and it should stay that way. 

Now to play a little devil's advocate.  I think the old HAD should be updated/upgraded as a framework to allow people to more easily build their own custom Web Dashboard for use in display and basic status/control Dashboards.  That is a framework design and some basic template for direction/use of what's possible.  Then other 3rd parties I'm sure would pick that up and develop dashboards that people could then use or buy.  I know I would.  In fact I've been looking at HAD thinking of what I could do with it or revise it.

Sorry if this is too direct but I've seen 2 systems in the last year go down this route... one is now floundering and is unstable and a mess and the other is on it's way....it's a race to the bottom to attract "New Users" and gotta have a "Shiny App" seems to be the attraction... frankly from the quality/level/experience of these "New Users"... Umm I'll pass....

Link to comment

I'm with simplextech on this one.  I've seen too many cases of what I term "GUI-First" development, wherein the phone or tablet is the primary focus, and as a result, the actual functionality of the solution ends up suffering, or in a couple of cases, the core functionality atrophies into the smaller set of "whizzy" and "cool" things that one can do from the limited tiny GUI display and the user-level-assumptions that go along with that.

I'll toss out an extreme idea here.  I'd like to see the ISY/Polisy solution architected rather differently:

a) Core functionality supported by a CLI that drives a REST API to do the work on the Polisy and the ISY.  This functionality would include:
      - adding/deleting/managing devices and scenes
     - diagnostics and health
     - uploading "compiled" programs and network resources
          a) which implies that programs would have a text-based "source code" that would be "compiled" for one's ISY/Polisy
    This would address a large need for being able to manage and version control large implementations - particularly good for installers, for example.

b) Core UI management functionality supported by a browser-based GUI that does a useful subset of the day-to-day activities involved in managing the Polisy/ISY.
    - includes uploading programs and network resources, but not authoring same

c) An "authoring" UI built on anything UDI likes, that would allow GUI-based program and network resource creation, much like the current Java-based IDE does.

d) A mobile solution that is a stripped down version of item b above, unless perhaps item b can be coded to work on both -- although I have to say that I find phone GUIs ported to a full-size web browser to be hard to use, annoying, and make me want to run to the command line instead... but to each their own.

e) A authorization-limited version of the REST API should be exposed for general user use, along with a "web toolkit" (examples and a library) that would facilitate technical users creating tablet-based or phone-based or even PC-based apps to do user-level actions to control the automation.  This would exclude management, and development activities, and thus should be a very small set of functions.  The fact that it has a separate user (or better yet, auth key) would ensure that even if someone reversed the app, that person couldn't gain access to the admin level actions for the Polisy/ISY.

I'm dreaming, of course... but if there's one thing I'd like to NOT see, it would be having UDI try to port the entire ISY experience to a phone.  Please, please, don't go there.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...