EE Times article by Michel Kohanim

[Michel Kohanim]

Hello everyone,

 

I think everyone of us, especially those using Polyglot, would enjoy this article:

 

http://www.eetimes.com/author.asp?section_id=36&doc_id=1332193

 

With kind regards,

Michel

[Teken]

Michel,

 

Great written article by you! From a high level couldn't someone say the node model you wrote about is just another *standards* of concept like weave, thread, Apple home kit, etc?

 

 

 

Sent from my iPhone using Tapatalk

[Jimbo.Automates]

Nice article!  Noticed "Node Metal Model" should be "Node Meta Model"?

[Michel Kohanim]

Thank you all. Yes, it should be Meta Model!

 

Teken, Node Meta Model describes HOW things should be described rather than describing/defining things. NMM does not enforce any dictionary or predefinition of things in the world. You can define anything you want and you are not bound by what some standards body decides you should fit into. For instance, how does one define Harmony Hub? What's the dictionary for it? What is it? And, yet, Jimbo defined one based on whatever he thought the Hub should be/behave/do. The same goes for Outback inverter that einstein.42 defined (except for Sunspec, you won't find any standards that define inverters. And, sunspect does not define anything else BUT inverters --> silos of things).

 

So, NMM is basically liberty for things: They can be whatever they want to be (or their creator decides for them).

 

With kind regards,

Michel

[Teken]

Hello Michel,

 

Appreciate the insight on the above. As of this writing is the Polyglot framework easily adapted and developer friendly to average programmer? I understood last year the Polyglot framework was undergoing more refinement and finalizing. Is that the case or is the current development SDK still in flux or something any vendor can start to use now and not have to worry about major changes in the framework?

 

I ask because several companies have committed to adding node server support. But only if such framework is considered finalized and public ready for development.

 

 

Sent from my iPhone using Tapatalk

[Michel Kohanim]

Hi Teken,

 

My pleasure. Polyglot is refined enough to the point that we are currently using it for our CEC project which is mission critical. Also, Polyglot is just a Python binding for NMM.

 

What we miss is marketing/videos and, in short, something to get developers/hackers excited. I think a Kickstarter project is a good idea but haven't thought it through yet.

 

With kind regards,

Michel

[Teken]

Hello Michel,

 

Some of this may be covered by the developers SDK so apologies if it is. Will the Polyglot framework ever be refined to a point where a person need only populate data points from the 3rd party product / service?

 

I suppose essentially what I'm asking is having basic to advanced templates already defined in the ISY Series Controller. Regarding a KS Project I would be lined up ready to go! I hope consideration for a Polyglot server is similar to what you proposed a few years ago but didn't materialize.

 

 

Sent from my iPhone using Tapatalk

[mwester]

Teken, I think the answer is a definite "maybe"...

 

With some effort, one could create a "fill-in-the-blanks" framework -- mostly.  At a high-level, the problem isn't so much the "what" that you would fill into the blanks, it's the "how".  The "what" would be things like "I need a value, integer ranging from 10 to 30, units are in degrees Celcius, and the value is sent FROM the device TO the ISY, and the name of the value is Heating Setpoint".   That's just data, and it's pretty easy to do.   The problem comes in the "how":  "Well, you fetch this value by reading the API key from the secure keystore locally, then open a network connection to an internet cloud service, and if it responds with a "OK" value when you connect and present the API key, then send another message, then parse the XML data block you get back, find the element named "Basement Thermostat", and in that element find the sub-element named "HSetPt", then read that value, and finally, use a formula to translate that from F to C, and if all that worked, then send that to the ISY".

 

It's that last part that makes a "fill in the blanks" node server pretty danged hard to do, 'cause that's coding -- not filling in blanks.  Not sure how you'll ever get around that.  And don't say "we need a custom node server scripting language" 'cause the very last thing the world needs right now is Yet Another D*** Scripting Language!

[Teken]

Teken, I think the answer is a definite "maybe"...

 

With some effort, one could create a "fill-in-the-blanks" framework -- mostly. At a high-level, the problem isn't so much the "what" that you would fill into the blanks, it's the "how". The "what" would be things like "I need a value, integer ranging from 10 to 30, units are in degrees Celcius, and the value is sent FROM the device TO the ISY, and the name of the value is Heating Setpoint". That's just data, and it's pretty easy to do. The problem comes in the "how": "Well, you fetch this value by reading the API key from the secure keystore locally, then open a network connection to an internet cloud service, and if it responds with a "OK" value when you connect and present the API key, then send another message, then parse the XML data block you get back, find the element named "Basement Thermostat", and in that element find the sub-element named "HSetPt", then read that value, and finally, use a formula to translate that from F to C, and if all that worked, then send that to the ISY".

 

It's that last part that makes a "fill in the blanks" node server pretty danged hard to do, 'cause that's coding -- not filling in blanks. Not sure how you'll ever get around that. And don't say "we need a custom node server scripting language" 'cause the very last thing the world needs right now is Yet Another D*** Scripting Language!

Mwester,

 

Your uncanny ability to dumb things down to the masses is right up there with my partner in crime Oberkc!!

 

Because I'm not a programmer and just some Average Joe. Some of these elements are harder for me to understand the first go round. I know in the past I read you created a node server using super tiny low power (ESP?) micro chip.

 

I don't know how strong you're in programming but if you can rewind the clock to a time where you knew nothing.

 

How do you rank being able to deploy a Polyglot node server from start to finish?

 

1 being very easy 5 being very hard.

 

 

Sent from my iPhone using Tapatalk

[Teken]

Polyglot wasn't around when mwester was 5 or 6 years old.

 

LOL . . .

[larryllix]

Michel.

Nicely written and expressed!

 

This sounds like you are redesigning DNP3 protocol.  It's a very popular SCADA protocol used the world over,

 

 Been there, done that.  It gets out of hand with brands completely incapable of talking to other brands due to the immenseness of the protocol.  I wrote an DNP3 analyser once. Just enough to fix the incompatibilities between two brands of equipment. WOW! I spent six months and maybe covered less than 10% of the known protocol, without any custom internal protocols.

 

For HA automation a subset of DNP3 could be defined in addition to the many other subsets already registered. Video widens the protocol somewhat but well defined already.

[Michel Kohanim]

Mwester,

 

Didn't really get what you mean. No one is suggesting another scripting language. And, we are not at all suggesting that NMM is just a generic fill-in-the-blanks framework for the masses (not yet at least). It's a developer tool so that developers can define whatever they want and that thing will immediately be able to participate in ISY's framework without ISY having to know what type of thing it is. Precisely what you did with ESP8266. So, I guess I do not understand.

 

larryllix,

 

NMM is definitely not DNP3. It's 100% opposite of DNP3 since it does not define things. It just defines how things should be defined so there are no super/subsets of anything.

 

With kind regards,

Michel

[Teken]

Mwester,

 

Didn't really get what you mean. No one is suggesting another scripting language. And, we are not at all suggesting that NMM is just a generic fill-in-the-blanks framework for the masses (not yet at least). It's a developer tool so that developers can define whatever they want and that thing will immediately be able to participate in ISY's framework without ISY having to know what type of thing it is. Precisely what you did with ESP8266. So, I guess I do not understand.

 

larryllix,

 

NMM is definitely not DNP3. It's 100% opposite of DNP3 since it does not define things. It just defines how things should be defined so there are no super/subsets of anything.

 

With kind regards,

Michel

 

Michel,

 

I truly believe anything that helps 3rd party developers take on, and adopt this framework is worth while. My hopes are 3rd part Devs will see value in this Polyglot framework to start their very own development as has been seen in the Vera / Homeseer forums. On a related tangent has the company been able to sort out the possibility to create node servers they could sell?

 

I think this is one of the pain points for some developers . . .

 

Also, there are a few highly requested node servers that have been created by others in this forum. My question is (IF) UDI will ever be able to offer Sonos, NEST, Phillips Hue,  (Name what ever is popular) as pre reconfigured nodes? 

[Michel Kohanim]

Teken,

 

NMM is very much the opposite of Vera, Smartthings, HomeSeer, etc. If a developer uses NMM (and understands the concepts), then the nodes themselves will understand each other even without an ISY, or a dictionary, or an app, or anything else. ISY is just a tool that has implemented NMM client in such a way that these nodes can immediately participate in ISY's framework, programs, and extensions (such as Alexa, Google Home, CEC, Energy Management, etc.).

 

One thing that I have to stress is that node servers do not have to be physical things. They can be services in the cloud (just like our geo fencing node server).

 

What we are thinking about, what we can do, and what we will ultimately do are very different topics. And, of course, they depend on demand.

 

With kind regards,

Michel

[Teken]

Teken,

 

NMM is very much the opposite of Vera, Smartthings, HomeSeer, etc. If a developer uses NMM (and understands the concepts), then the nodes themselves will understand each other even without an ISY, or a dictionary, or an app, or anything else. ISY is just a tool that has implemented NMM client in such a way that these nodes can immediately participate in ISY's framework, programs, and extensions (such as Alexa, Google Home, CEC, Energy Management, etc.).

 

One thing that I have to stress is that node servers do not have to be physical things. They can be services in the cloud (just like our geo fencing node server).

 

What we are thinking about, what we can do, and what we will ultimately do are very different topics. And, of course, they depend on demand.

 

With kind regards,

Michel

 

Now, the areas bolded in red is what I didn't know or understand. Does the NMM consortium group have or will offer a means to certify a node server / node service meets all of the requirements?  

[Michel Kohanim]

Teken,

 

There are no consortiums, bodies, or otherwise certification authorities. The point is that you don't need them UNLESS you want all things of type-x to have the same attributes/methods. And, even then, you will only need a compliance layer.

 

I think we are getting too deep into theory. What we really need to talk about should be related to ISY/UDI. Such as:

1. Are there any demand for a marketplace of things for ISY? And, by things, I mean anything. They don't have to be devices, lights, thermostats, etc. It could be what Mwester invented or an expiration RFID on milk cartons. Again, they could be anything

2. If so, how can we reach developers and get them excited?

3. What other things should be included? Such as those you have on your list (which are already supported by Polyglot)

 

With kind regards,

Michel

[Teken]

From a practical stand point I would say offer real world examples and demo of the Polyglot framework in use.

 

If I saw Sonos, NEST, Phillips Hue, what ever operating in a You Tube video with a high level over view with links to the developer SDK etc. That would be a good first step along with Twitter, FaceBook, exposure etc.

 

I think the biggest opportunity is sending out this information to tech websites that can help bring more awareness. Another important part is working with partners who can help cross promote the framework while using it in their products.

 

Another opportunity for UDI for revenue stream is offering to provide the development of said node server to connect to what ever.

 

As you noted the geo fence development was a great working example.

 

 

Sent from my iPhone using Tapatalk

[Envirogreen]

Michel

 

One other item that will help get developers excited is an existing Consumer base

 

That means making sure all existing users have an easy path to adoption...selling a rPi preinstalled plus a couple of node servers should generate revenue and accelerate adoption

[larryllix]

Michel

 

One other item that will help get developers excited is an existing Consumer base

 

That means making sure all existing users have an easy path to adoption...selling a rPi preinstalled plus a couple of node servers should generate revenue and accelerate adoption

Excellent! A multilevel hardware/software offering may also be a winner.

 

Offer the hardware, hardware with basic polyglot, just polyglot, hardware polyglot and one installed node server, complete with paper instructions enough to reveal the whole soft manual stored in the ISY994x box.

 

Sent from my SGH-I257M using Tapatalk

Edited August 27, 2017 by larryllix

[Michel Kohanim]

Thank you all for all the feedback. I think we should start with putting a video together. Does anyone know a good videographer/video editor?

 

With kind regards,

Michel

[larryllix]

Teken,

 

NMM is very much the opposite of Vera, Smartthings, HomeSeer, etc. If a developer uses NMM (and understands the concepts), then the nodes themselves will understand each other even without an ISY, or a dictionary, or an app, or anything else. ISY is just a tool that has implemented NMM client in such a way that these nodes can immediately participate in ISY's framework, programs, and extensions (such as Alexa, Google Home, CEC, Energy Management, etc.).

 

One thing that I have to stress is that node servers do not have to be physical things. They can be services in the cloud (just like our geo fencing node server).

 

What we are thinking about, what we can do, and what we will ultimately do are very different topics. And, of course, they depend on demand.

 

With kind regards,

Michel

Trying to understand your concept,  please verify my paraphrasing/analogy.

 

NMM sounds like a definition for a protocol  that will allow a device to  send a complete device descriptor block to ISY (or other smart device) and ISY can instantly self install  node pieces that understand all the given aspect/parameters to be expected from the device.

 

In effect,  ISY could start out knowing nothing about any device.  When a device first connects to ISY (or other smart device), it sends it's personality and/or configuration. ISY would then configure itself, installing all the styles of node drivers it was told about and now understands the remote device with all it's nuances. 

 

On a simpler scale, it would be Plug'n Play, but on a smaller chunk scale (not on a whole device driver scale), to be able to represent any possible new device with many less drivers than one large one for every device produced. 

 

 

Simplified protocol talk

DEVICE. "I am a thing-a-ma-jig . I contain an MS=On/Off, Brightness Level=0-100%, Battery Voltage=0-3.5 volts, Angle Detector=0-360 degrees" -----> ISY  "OK.... Installed Thing-a-ma-jig.....Ready for values"

 

Thanks Michel

[Michel Kohanim]

Hi larryllix,

 

Very very close with one exception in the following:

"DEVICE. "I am a thing-a-ma-jig . I contain an MS=On/Off, Brightness Level=0-100%, Battery Voltage=0-3.5 volts, Angle Detector=0-360 degrees" -----> ISY  "OK.... Installed Thing-a-ma-jig.....Ready for values"

It's NOT mandatory for the device to say "I am a thing-a-ma-jig" and the properties you listed do not have to be anything ISY has ever seen before. For instance, a property could be "thing-a-ma-jig"

 

To make it even simpler, all the device needs to let ISY know are:

1. You can do this to me (send me these commands and parameters)

2. I can do these to you (send you commands and parameters such as number of physical button presses)

3. These are my properties

 

All the above are completely FREE FORM and developer defined. No dictionaries, etc.

 

So, in effect, you can define an autonomous car if you wished. Or, a robot. It's up to you.

 

Now, the challenge is to make this simplified to the point that everyone understands the concepts. And, as you know, marketing is not one of our expertise (yet)!

 

With kind regards,

Michel

[Michel Kohanim]

Hi larryllix,

 

Thank you! Actually Chris is the brain behind NMM so one of the Ms is not for Michel!

When can we start writing device block handlers in our ISY994X boxes?

Ah, I forgot to tell you the best part! There's absolutely NO NEED to write anything inside ISY including device blocks. Polyglot (or something like it) shall remain and perhaps one day both ISY and Polyglot can be combined into one (I think that's what you are referring to). The last part depends on our resources.

 

With kind regards,

Michel

[larryllix]

Hi larryllix,

 

Thank you! Actually Chris is the brain behind NMM so one of the Ms is not for Michel!

 

Ah, I forgot to tell you the best part! There's absolutely NO NEED to write anything inside ISY including device blocks. Polyglot (or something like it) shall remain and perhaps one day both ISY and Polyglot can be combined into one (I think that's what you are referring to). The last part depends on our resources.

 

With kind regards,

Michel

Finding this fascinating...doesn't that mean passing  a specific node driver code to the other end, making the other end CPU code dependant and the code hardware dependant?

 

OTOH, Perhaps a scripting language that already understands individual box hardware (sound output, video, Insteon PLM, wired siren) is the underlying secret then? That would mean  ISY would not really be needing much OS change,  just the ISY994X box would get smarter and understand where to send what node signal. ISY would become a smart peripheral to it, somewhat.

[Michel Kohanim]

Hi larryllix,

 

Neither. And this is what makes NMM challenging to describe. ISY understands commands, properties, and events. What the contents of commands, properties, events "mean" are completely immaterial to ISY as long as it knows how to represent/present them to ISY User (Human Being or AI). So, there are really no drivers in ISY except for "communications, commissioning, and security".

 

Let's try an example:

1. ISY currently does not know how to do anything with NEST

2. Someone creates a NEST Node Server (on Polyglot or in the cloud) and the only thing this node server is telling ISY is:

- You can change cool and heat set points with a range of a valid values

- You can dim/brighten the backlight

- You can change the mode with an enumeration of valid values

3. You integrate this to ISY. ISY does not know NEST is a thermostat. So, purely based on #2:

- It creates a GUI that shows you commands for changing set points, dim/brighten/mode

- It creates hooks for scene management (say you want NEST to be in the same scene as your INSTOEN thermostat so that pressing button on thermostat does something to INSTEON or vice versa)

- It creates hooks for programs using valid enumeration for everything defined in #2

+ a lot of other things which are left out for the sake of simplicity

 

Now, what you do with #3 is completely up to you: You can control NEST through UI, you can put it in a scene with anything else, or you can have programs for it just like any other device in ISY. There's absolutely NO code change on ISY. None.

 

In short, NMM moves the intelligence out of the model and moves it up one level to the actual user (or AI) because, at the end of the day, we are not talking about some organic society of things that figure out how to make a civilization (but NMM does allow for this). We are talking about some higher level intelligent being knowing what to do with a thing (through ISY for our purposes).

 

I hope it makes sense.

 

With kind regards,

Michel