Sedona Moving Forward - Beyond 1.2.28

[Calvin Slater]

What is your wish list of new features moving forward from version 1.2.28, which is now almost 7 years old?

Mine are the following:

1. A standardized kit for common I/O; Mainly BOs, AOs, UIs, Serial devices etc. Implemented as a service, that is real-time capable, with standardized native methods. Something that would also work with microcontroller based devices, even though we have largely moved away from micros in hardware. I will create a video explaining what I am talking about shortly.

2. Component order of execution and the ability re-arrange component order in the app tree.

3. Option for JSON formatting in addition to XML for applications, manifests, etc. (Prepare for browser based editors/device managers)

4. JavaScript version of Sedona compiler.

5. Further development of the Web kit and API. Authentication, encryption, etc.

I know this is a lot of stuff, just throwing it out there. What are your thoughts?

Regards

Calvin

[znetsovCC]

That is a pretty nice wish list. I would say that each item on this list is important to the future of Sedona. One thing to keep in mind is that if a new Sedona version is released (such as 1.3 for example), all manufacturers would have to move to it in order to maintain compatibility between manufacturers. 

[M_E]

A few initial thoughts on these:

A standardized kit for common I/O with standardized native methods is a good idea. But I doubt if it would be possible in practice. I'll wait for your video for a better understanding.

About not being able to determine component order of execution: It does seem desirable when you think about it. But in my personal experience, I didn't come across any critical situation due to this. Has anybody? Is there a practical way of enabling this without making it overly complicated - in terms of both user-experience and the Sedona engine.

Following on znetsovCC's comment regarding the need to maintain compatibility between manufacturers : Unfortunately, compatibility between manufacturers is already sacrificed in 1.2.28 with different manufacturers running modified flavors of it. Perhaps a new version can also address this problem.

[znetsovCC]

A standardized IO kit would be difficult, but certainly not impossible. There are only so many types of IO in this industry and now we have more abstraction between us and hardware such as Linux OS. If I were to start anywhere, I would probably start with Linux devices.

It would be cool to define order of execution, but it is not really necessary and there is a simpler workaround in the SVM. You simply define the order of execution as 1. Read inputs (all) 2. Perform logic and calculations 3. Execute Outputs at the end. It is pretty simple but it works for HVAC equipment. After all, we are not driving very time-sensitive equipment.

There certainly is a lot of interoperability between Sedona devices from different manufacturers. There are about 5-6 Sedona manufacturers right now and only one of them is NOT interoperable with the rest because they use Sedona 1.0 while everyone else uses 1.2

I can use the Contemporary Controls Sedona Application Editor on Sedona devices from other manufacturers as long as I have the kits/manifests for those devices. 

[Cory Mosiman]

What about the ability to add additional metadata as part of a Sedona application?  It seems like these could be created in the SAX file.

• I am not any type of expert in this, but it appears that Sedona allows the creation of arrays, which could be used to hold 'tagsets' (let's just call these sets of Haystack tags).
• Depending on the metadata schema desired (say Haystack or Brick), a new property could be added to a component, being either an array of strings (Haystack tagset) or a string (Brick class)

Thougts?  I know Alper is using Haystack tags in Sandstar, so just curious if there is also desire to bring into here?

[znetsovCC]

Cory,

It is possible to add metadata tags to Sedona components. This would be useful for IO (physical) and Virtual (soft) points which are exposed to the network, whether that be BACnet or Haystack or other networks. However, the approach to tagging can be tackled in several different ways. From what we know so far, customers would rather have a quick and easy, or best scenario - an automatic way of applying tags rather than spending time on tagging.  Perhaps a web-based method may be quicker or even fully automated. Tags are very useful now and will be absolutely necessary in the near future as the world of IoT (including connected buildings) keeps growing. Manual tagging of points is totally fine on a small scale. Automatic tagging can be accomplished with "application profiles" containing pre-tagged points, or cookie-cutter pre-programmed and pre-tagged project files containing Sedona wire sheet program, controller configuration, tags, etc. all encapsulated in a single project file for different sorts of applications. This is what our BASbackup tool does and once we add Haystack tagging to BASpi, it will backup and clone tags as well. There are many ways of accomplishing metadata tags.

[Cory Mosiman]

Hey all - would be interested to continue this conversation.  Have there ever been meetups / discussions?  How does Sedona drive roadmap / etc?

[Romain B]

EasyIO release sedona 2.0 but JCI don't want continue to release source code so forget compatibility between manufacturers.

Nobody want take leadership for Sedona framework.

Sedona need a real update, I think Contemporary Controls must take this leadership and continue to maintain this awesome project.

[*Air bear*]

more meaningful list sort in the AV/BV linking dialog

[Alper Üzmezler]

Project sandstar is open sourced. We are working beyond it. My idea is to create source available of all code for Mobilytik, Visualytik, Project Sandstar to move the industry forward. 

https://gitlab.com/project-sandstar/sandstar

[Ahmed Desoky]

Please, could you have any illustrated video or documents  for  sandstar  and its applications?