Meetup 26 Resources

Meetups/26/2025-03-27-minutes.md

@@ -0,0 +1,185 @@
+# Meeting Minutes
+
+## Info
+
+:date: **Date:** 27 March 2025
+
+### :bust_in_silhouette: Participants
+
+<!-- This list will copied over from the meeting tool -->
+- Ege Korkan
+- Cristiano Aguzzi
+- Henk Spaaj
+- Kunihiko Toumura
+- Jase Kraft
+- Tomoaki Mizushima
+- Sibla, Wilfried
+- Tamoghna Ojha
+- Piotr Sowiński
+- Yusuf Koç
+
+:writing_hand: **Scribe:** Ege
+
+----
+
+### Introduction
+
+- Cris: Welcome Everyone!
+
+### News
+
+Cris: No new meetup planned. You can let us know if you want to present something.
+
+Cris: We have the tutorial shaping up. Also 3 projects for the Google Summer of Code are available from Eclipse Thingweb.
+
+Cris: Joining the groups is free, you can join using the button.
+
+### Meetup Presentation
+
+Cris: We have Henk Spaaj here. He is a retired Senior Software Engineer and development manager. He was educated as Electronics Engineer and has over 30 years of software development experience in embedded industrial and consumer solutions
+
+Henk: I started with MQTT and myzone. Then went to NGSI-LD. Working with WoT since 2023.
+
+Henk: I bought a piece of land had pump house built a pump house on it and the one you see in the picture. The house itself is a bit further away and if something goes something goes wrong in that pump house then, I'd rather be ahead of the game than finding out that the water is frozen.
+
+
+Henk: I assume the IoT devices can be anything. I'll get a bit deeper into that in a minute. It doesn't have to be a WoT device. In fact, the assumption is that most of them are not.
+
+Henk: Consumers do not talk to the devices directly. They talk to a digital twin.
+
+Henk: You can add services.
+
+Henk: This is more secure than the servers. Also it is a bit against the current design of WoT. This way, the Consumer are talking to a single endpoint.
+
+Henk: Security is a real issue. Not good encryption, weak auth mechanisms. It is good that WoT is going around this a bit.
+
+Henk: A casino database was hacked through a smart fish tank thermometer.
+
+Henk: In HiveOT, Things do not run servers, if they do they get secured behind a firewall. This greatly reduces the attack surface.
+
+Henk: By having a hub, you can centralize authentication and authorization. FW updates can be centralized. Interaction experience is uniform.
+
+Henk: WoT devices can be integrated easily, as well as many other devices. Everything is exposed as a WoT device again.
+
+Henk: We have added some plugins as well. Like history information etc.
+
+Henk: The DT router has interesting features. You can add routers to external devices or create TDs for services.
+
+Henk: (shows the action flow)
+
+Henk: The router can do validation like access right checking. Actions can be kept as a queue.
+
+Henk: (shows event flow, also valid for property updates)
+
+Henk: All messages have an envelope, like message id, timestamp etc.
+
+Henk: You can actually use the bindings independent from the hub.
+
+Henk: Current services are: Launcher, history of events, web ui, server CA management, and more.
+
+Henk: Protocol bindings include zwave, insteon, 1-wire
+
+Henk: The command line has some utilities. You can generate client code and also vocabularies.
+
+Henk: For the demo now. This is an HTMX based UI.
+
+Henk: You can click on a property and see history.
+
+Henk: (shows a TD)
+
+Henk: I know that this is not a compliant TD. The forms are omitted.
+
+Henk: Without type annotations, I don't think that the standards will go far.
+
+Henk: I was struggling with enums . I am now going with oneOf so that I can add title.
+
+Henk: HiveOT also has a directory. It shows services and Things, based on tags developed for HiveOT.
+
+Henk: Some devices have a lot of properties. Like this multi sensor having 120. The TD is massive and that is without forms.
+
+Henk: So you can ask how we can interact with Things without forms.
+
+Henk: Forms will be included in the TD but they add little value as all interactions with Things use the single hub connection. So the expressive power of forms is not needed.
+
+Henk: The hubcli commandline utility is meant for administrators. You can see running services for example.
+
+Henk: Now onto the challenges.
+
+Henk: It is better to leave your opinions outside. Reading the specs are important.
+
+Henk: I think that some can be addressed to increase adoption.
+
+Henk: There is no relationship between affordances. Like what happens when a property and action have the same names. You are on your own.
+
+Henk: This is needed to solve a problem. For example an action that changes the state, like switching that changes the switch state. A switch can also be toggled manually. So it needs a property for the state.
+
+Henk: To link these, I give the same name. This problem needs to be solved.
+
+Henk: when to choose actions vs properties. There is no guidance so I made my own rules.
+
+Henk: Same for events vs properties. So properties are internal state and events are external states in hiveot.
+
+Henk: Also for results of actions. It is unclear. The spec says it is dependent on the protocol. It is not nice for a hub as it should be generic.
+
+Henk: There are some other small things like multi-line descriptions and comments.
+
+Henk: Also map type would be nice.
+
+### Discussion
+
+Cris: We should definitely collect the challenges. Very valuable for working group.
+
+Yusuf: The `oneOf` solution is nice. How do you handle property values that are dependent on other properties? Did you face such a case?
+
+Henk: Not myself but I can see that happening.
+
+Ege: I see this use case at Siemens.
+
+Yusuf: We should exchange on this.
+
+Cris: Can you elaborate on sharing the SSE?
+
+Henk: The standard assumes a new connection per request. So I define a message envelope. I defined 3 types of envelopes for all interaction with all things over a single SSE connection. It is quite powerful this way.
+
+Ege: Do you have TDs for protocols like zwave, 1wire etc?
+
+Henk: The hub generates the TD from the device information.
+
+Ege: Are you interested in improving the standards?
+
+Henk: I can make some proposal. I can make a proposal with some text.
+
+Ege: I did not understand the issue with the type map
+
+Henk: (shows the slide)
+
+Ege: You can `additionalProperties`
+
+## :envelope_with_arrow: Feedbacks
+
+- No notion of correlation or relationship between affordances. If the name of an action and property is same, is there a relationship? In HiveOT, an action switch triggers the switch event and updates the switch property.
+- The difference between action and property is not always clear.
+- Similar to above, difference between event and property is not clear.
+- It is not clear how one would get the results of an action.
+- Without a standard vocabulary, it is difficult to have a meaning for the affordances. HiveOT developed its own.
+- Doing the workaround with `oneOf` to add a title/desc for enums is annoying
+- It would be nice to support multi-line description, title, comment.
+- There is no way to read the last event value, i.e. `readevent`
+- Sometimes there are *basic* properties, they are useful. Sometimes there are advanced properties like configuration etc. HiveOT has a vocab to indicate advanced vs basic properties.
+- It is not possible to indicate global/shared constants or values between things.
+- It is annoying that each affordance has a form. Most Things have a single protocol
+- When a connection is shared among Things (SSE or WS), we need definitely a message envelope with thingID, clientID etc.
+- We cannot describe if an action has multiple responses. We use correlationID in HiveOT
+- It is not possible to confirm writing to a property. It can take a while for a property update to happen, it can fail etc.
+- Even with alternative response feature, it is not always possible to know that an action response is the alternative one.
+- A standard message envelope separate from the protocol bindings would be good.
+- We cannot express authorization rules based on capabilities.
+- It is annoying for a language like golang that a term can have string or array type.
+- RPC cannot be described
+
+## Presentation Summary
+
+- How is the data structure for historical data?
+- td2go -> You mean it is like OpenAPI stub generator?
+- vocab generator: Who/what uses the vocab and how does it look like?
+- Button press event history -> How does it look like

Meetups/Readme.md

@@ -5,6 +5,16 @@ This readme contains the links to minutes, presentation files and the recordings
 
 Note: Presentation files use the pattern `YEAR-MONTH-WoTCG-EVENTNAME-PRESENTERNAME.FILETYPE`.
 
+## Meetup 26
+
+- Name: How the Hive of Things - HiveOT - embraces WoT
+- Presenter(s): Henk Spaaj
+- Date: 27 March 2025
+- [Presenter Slides](./26/2025-03-WoTCG-Meetup26-HiveOT.pdf)
+- Intro Slides: [Google Slides](https://docs.google.com/presentation/d/192ScNSZCw31CBW2r9Omipr5hJTe8fLsP9tB6ZSNsbVw/edit?usp=sharing) | [PDF](./26/2025-03-WoTCG-Meetup26-AguzziKorkan.pdf)
+- [Video](https://youtu.be/JxGcW70tqfk)
+- [Minutes](./26/2025-03-27-minutes.md)
+
 ## Meetup 25
 
 - Name: An Introduction to Eclipse LMOS