Teken Posted June 24, 2020 Posted June 24, 2020 MODBUS TCP: This would be a good time to consider integration of this protocol. Doing so would open the Polyisy to (huge) and existing market where legacy sensors are plentiful and reliable. The net result is more adoption, increased sales, and market share. Ultimately, this would allow many of us to deploy Enterprise level hardware that is rock solid, proven, and robust. This would be a good time to create a purpose built (native) Node Server . . .
bpwwer Posted June 24, 2020 Posted June 24, 2020 19 minutes ago, Teken said: MODBUS TCP: This would be a good time to consider integration of this protocol. Doing so would open the Polyisy to (huge) and existing market where legacy sensors are plentiful and reliable. The net result is more adoption, increased sales, and market share. Ultimately, this would allow many of us to deploy Enterprise level hardware that is rock solid, proven, and robust. This would be a good time to create a purpose built (native) Node Server . . . Implementing a general data protocol like MODBUS in a node server doesn't seem very realistic. That's like asking for a zwave node server. Supporting the protocol without supporting the devices that communicate over it wouldn't be of much use. Given that MODBUS:TCP is just a wrapper on top of standard TCP socket communication, it's not hard to implement a node server for a specific device (or device class) that communicates over MODBUS:TCP. It may be better to ask for node servers for specific MODBUS devices.
Teken Posted June 24, 2020 Posted June 24, 2020 7 minutes ago, bpwwer said: Implementing a general data protocol like MODBUS in a node server doesn't seem very realistic. That's like asking for a zwave node server. Supporting the protocol without supporting the devices that communicate over it wouldn't be of much use. Given that MODBUS:TCP is just a wrapper on top of standard TCP socket communication, it's not hard to implement a node server for a specific device (or device class) that communicates over MODBUS:TCP. It may be better to ask for node servers for specific MODBUS devices. The protocol needs to be supported in the hardware first and once done something like this as explained here:
larryllix Posted June 24, 2020 Posted June 24, 2020 10 minutes ago, bpwwer said: Implementing a general data protocol like MODBUS in a node server doesn't seem very realistic. That's like asking for a zwave node server. Supporting the protocol without supporting the devices that communicate over it wouldn't be of much use. Given that MODBUS:TCP is just a wrapper on top of standard TCP socket communication, it's not hard to implement a node server for a specific device (or device class) that communicates over MODBUS:TCP. It may be better to ask for node servers for specific MODBUS devices. @Teken I had a short discussion with io_guy years ago about a ModBus node and the first question that comes up is which of the 65536 addresses are what is wanted. Then I was stumped. The SunSpec protocol that Outback and others use floats blocks of Modbus addresses and discovers them on-the-fly, so that manufacturers can add and subtract equipment as they desire. Modbus is a very basic level of the OSI hierarchy (like specifying ascii, on an RS-232 interface) , so I agree with bpwwer above. Many specifics need to added and many different and specific NSes would need to be created.
larryllix Posted June 24, 2020 Posted June 24, 2020 7 minutes ago, Teken said: The protocol needs to be supported in the hardware first and once done something like this as explained here: ISY coding could not perform the higher level protocols needed. The NS would have to dump 65,536 variables on ISY and let ISY sort them all out.
Teken Posted July 9, 2020 Posted July 9, 2020 Roll Back: I haven't reviewed this entire thread again due to limited time. But would like to ask the team to consider a formal process where Node Server Developers have the ability to place the last version of software in case of a major bug. If someone can correct me if I am wrong but does a Polisy backup restore the system and all of its node servers to that snap shot in time?!? So if dog application is on 1.00 and later is updated to 1.01 and there's a major bug. Can I just use the Polisy restore from a older backup to restore the system to 1.00?? Regardless, of that fact there should be a *Prior Version* held in the Node Server Store to let the user quickly downgrade. Thank You!
markv58 Posted July 9, 2020 Posted July 9, 2020 @Teken It's my experience that the Polisy backup just stores config and data stuff. During the restore the current version of the NodeServers are downloaded and installed. There is a way to retrieve previous versions from the GitHub by going through the history, kind of a pain but I have done it a few times.
Teken Posted July 9, 2020 Posted July 9, 2020 12 minutes ago, markv58 said: @Teken It's my experience that the Polisy backup just stores config and data stuff. During the restore the current version of the NodeServers are downloaded and installed. There is a way to retrieve previous versions from the GitHub by going through the history, kind of a pain but I have done it a few times. Appreciate the insight so my feature enhancement request still stands for the Node Server Store. There should be an option to select a previous version in case of a unknown bug impacting the latest release. I would also go so far as say (IF) the Node Server backup truly does poll the system for the latest and greatest - don't! There should be an option box within the Polyisy *Settings* for the user to enable / disable this behavior - if it exists.
markv58 Posted July 9, 2020 Posted July 9, 2020 I would agree that there should be an easy way to rollback an update should it be a clunker, it happens. I sent a stinker out one time and scrambled like a mad man to get that straightened out before all heck broke loose.
Teken Posted July 9, 2020 Posted July 9, 2020 1 minute ago, markv58 said: I would agree that there should be an easy way to rollback an update should it be a clunker, it happens. I sent a stinker out one time and scrambled like a mad man to get that straightened out before all heck broke loose. All of the developers offering their hard work, sweat equity, with respect to Node Servers is greatly appreciated. There isn't a person on this forum who would think poorly of you or others for a unknown bug! This is pretty much the role of Alpha / Beta testing and continuous iterating until such time as the application is rock solid. When I think back to different small to large software applications its quite apparent to me everyone here tries to follows all of the best practices for dog food testing. It never ceases to amaze me when someone who doesn't even have the same hardware is able to cook up some kind of voodoo magic simply based on a open API or one that has been reversed engineered via packet sniffing. Thank You! ??
lilyoyo1 Posted July 10, 2020 Posted July 10, 2020 On 7/9/2020 at 12:55 PM, Teken said: All of the developers offering their hard work, sweat equity, with respect to Node Servers is greatly appreciated. There isn't a person on this forum who would think poorly of you or others for a unknown bug! This is pretty much the role of Alpha / Beta testing and continuous iterating until such time as the application is rock solid. When I think back to different small to large software applications its quite apparent to me everyone here tries to follows all of the best practices for dog food testing. It never ceases to amaze me when someone who doesn't even have the same hardware is able to cook up some kind of voodoo magic simply based on a open API or one that has been reversed engineered via packet sniffing. Thank You! ?? ????. Lol
lilyoyo1 Posted July 10, 2020 Posted July 10, 2020 On 7/9/2020 at 12:55 PM, Teken said: All of the developers offering their hard work, sweat equity, with respect to Node Servers is greatly appreciated. There isn't a person on this forum who would think poorly of you or others for a unknown bug! This is pretty much the role of Alpha / Beta testing and continuous iterating until such time as the application is rock solid. When I think back to different small to large software applications its quite apparent to me everyone here tries to follows all of the best practices for dog food testing. It never ceases to amaze me when someone who doesn't even have the same hardware is able to cook up some kind of voodoo magic simply based on a open API or one that has been reversed engineered via packet sniffing. Thank You! ?? I agree with you. My dad was a computer consultant. I remember watching him program as a kid thinking how boring it looked. Seeing what it takes to do what they do amazes me now which is why I don't complain or say how easy something is to do. Whether it's the developers or UDI, I know how much goes into making it all work for us.... Which is why I never got into it in the first place. Kuddos
JBanaszak Posted July 10, 2020 Posted July 10, 2020 Almost on topic, I would like to request a way to tell when a new Nodeserver is loaded to the store. It could be as simple as the "last upload date" or similar. Now that we are up to 82 nodeservers, it takes quite a bit of hunting to figure out which one is number 83.....!
Teken Posted July 10, 2020 Posted July 10, 2020 6 minutes ago, JBanaszak said: Almost on topic, I would like to request a way to tell when a new Nodeserver is loaded to the store. It could be as simple as the "last upload date" or similar. Now that we are up to 82 nodeservers, it takes quite a bit of hunting to figure out which one is number 83.....! I'm a visual kind of guy so would like to suggest any new server be highlighted to be a different color. Perhaps like a traffic light green new, yellow update, red beta?
markv58 Posted July 10, 2020 Posted July 10, 2020 Sorted or a way to sort by Newest would work for me.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.