Xeto is a data-only type system. The name is derived from the phrase "eXtensible Explicitly Typed Objects". Xeto defines a simple plain text format used to declare types and to exchange typed data. It is designed to build and validate Project Haystack data models. But Xeto is general purpose enough to use with any structured data including CSV, JSON, or SQL data.
This repository is used to manage the source code for the standard libraries.
Update 10/14/24 1
Been very busy at work these days. I'm excited to jump back into this project. I am not sure how much interest there is in my further development of GL36 specs. Please use the "watch this project" as a way of telling me you're interested! I'll use it as a metric I can follow to determine industry interest. I do plan on continuing this work regardless, I am just curious who out there might make use of it. You can also drop me an email. Thank you for being so patient on this! I will be at Skyposium this week so try to find me there if you're around!
-Cheers
Update 9/30/24 1
Today I uploaded a list of equipoment to be covered and their reference setions in GL36.
You can find it here List Of Equipment
Today I spent some time trying to get my updated G36SingleZoneAhu spec to pass fitsExplain() on a test skyspark model I developed that should pass. I think my model isn't done correctly as it's not passing the fitsExplain() properly. So I am going further into the model's various points indicated in the axon errors (see below)
msg:"6 errors"
msg:"Missing required Point: ph.points::DischargeFanRunCmd"
msg:"Missing required Point: ph.points::DischargeFanSpeedCmd"
msg:"Missing required Point: ph.points::OutsideDamperCmd"
msg:"Missing required Point: ashrae.g36::CoolingSignal"
msg:"Missing required Point: ashrae.g36::HeatingSignal"
msg:"Ambiguous match for Point: ph.points::ZoneAirTempSensor
This has shown me that I need to keep working on getting the spec to be dynamic enough to accept the GL36 equipment types that fit a Single Zone AHU. I must rethink how the spec checks the cooling/heating processes. Right now I am just using a chilledWaterCooling tag, but a modern-day single-zone RTU could have VRF cooling/heating and this spec shouldn't balk at that. Anyway, I continue to poke at this and refine my Xeto code. Stay tuned,
Cheers, EnochRick
I figured out the issue I was having yesterday with my testing setup in skyspark. I modified my test procedure in EnochRicksNotes to correct the issue. Things are now working properly again with this set of xeto files.
I wrote up my process and references in a note file you can find here: EnochRicksNotes. This includes detailed step-by-step instructions on how to compile your xeto files and bring them into your SkySpark environment for use and testing! Please scroll to the bottom to see my process step-by-step.
I also implemented the "choice" type for the cooling signal and heating signal which fixed the ambiguous match exception. Furthermore, I made the call to version ph.points and added the specs for things that were previously in the ashrae.g36/misc-points.xeto under ashrae.g36.
Added entries to the bottom of the following files in ph.points:
- air-pressure.xeto
- damper.xeto
- fan.xeto
ph.points has been versioned with these changed to v0.1.2 and the ashrae.g36/lib.xeto now requires this updated version.
I am having issues in skyspark that I am not having with the CLI axon.
I am working on it, right now be cautious with this fork and please realize it's a work in progress. My issue is in my new ph.points version. It complies in CLI, but skyspark isnt happy with it. Digging in, will keep you posted.
Known Issues:
-
#1: Ambiguous types for : CoolingSignal and HeatingSignal – I tried to set these up as OR types (trying to test how dynamic I can make the “fit” function). It throws an “Ambiguous match for Point: ashrae.g36::CoolingSignal” error when using the “fitsExplain()”. This is likely my fault for not quite working this out per Xeto’s intended use of “or” types. I now see I need to make them a "choice" type and reference the applicable entity types for GL36.
-
#2: SiteAirPressureSensor was created, and it's intended to be a “Building Static Pressure” type, but I didn’t see a tag in Haystack for “whole building stuff” beyond the “site” tag. Not sure the “site” tag’s intended use fits what I did here.
-
3# The
misc-points.xetonow has some types that could probably be merged into specific ph.points files, which would fit their intent and clean upmisc-points.xeto. I may make these changes to the source, but I am still testing the waters with this, so in the meantime, please “bless this mess” 😉 -
4#: fix
ph.pointsso local copy of skyspark can compile it (had an issue with my copy of the original repo, restored and this corrected my issue locally)
Cheers - EnochRick
End of day update: Moved a bunch of new types into the misc-points.xeto. Had to define some new things to fit the Guideline's intent for certain control sequences (like building pressure control).
Late Morning, Update 2: Figured it out, my new code is here now!
Capt'n's Log: AM: I just did a clone of this repository on a different machine first thing this morning and learned that I have not yet fully understood how to push my changes up. I am working on this today. I'll post here once I have learned how to do this the way I expect (still reading the git manual https://git-scm.com/docs/user-manual) Cheers - EnochRick
I forked this project for a couple of reasons:
- I wanted to learn the GitHub workflow and put it into practice to learn how it's done
- I wanted to learn Xeto and be able to build and use it in axon
- I noticed the GL36 example wasn't how I'd personally interpret GL36 to be used in Xeto, so I updated it and provided comments.
I hope folks find my changes useful! Cheers - EnochRick