Blockquote
I know that OH is Java so that Java should obviously be preferred. So why not sticking to developing one single scripting model with Java instead of providing plenty of languages? I started with DSL and the XTend stuff. I coded all in DSL and it was a real pain for me as I had no Java background. Facing debugging issues, I was encouraged to migrate to JSR223 (remember the nextGen engine speech) so I hardly moved all to JSR223 and now everyone says JSR223 is dead arguing the EOL of Python2 that was already there in 2008. So if OH scripting is not going back and forth, at least we can say the plan is quite erratic.
I had not seen it and it is a good start.
Here you are giving the [great] list of bindings available in OH to interact with the hardware. But we miss bricks to model standard behaviors between them, built over them. The semantic model has the abstraction level of the bricks I am talking about even if it currently misses a packaging to make development user-friendly
To clarify, let me list the expected behaviors of each brick that one would expect to find to have a “ready to deploy” user experience:
Rooms:
- attach devices to rooms,
- map rooms to map the house (and use it in the UIs),
- locate users based on available technologies (wallswitches, cameras, sensors, wearables, BLE and network positioning, appliance usage, predictive users displacements),
- provide functionalities per room that can be reused by other bricks.
For example, is there a TTS device available, multimedia devices (music, TV, radio), dimming or scenario lighting, sensors, cameras… So other bricks can interact with the rooms in a standard way.
Access management (the tricky topic):
- methods to locate user (mainly GPS and networks detection, RFID),
- standard rules to welcome users (when far, in approach, arriving and at home), method to welcome users (what are the “access doors” that trigger welcoming),
- types of welcoming per user profile (supervisor of the system does not get the same welcome information as children),
- content of welcoming (data sources, topics, preferences).
- Presence management: at home, nightly mode, absence and associated scenarios.
- Scenarios when leaving home (turns lights, close doors…).
- Handling guest access (concierge and guest at home (access to networks, allowed functions, tutorials for guest at home).
- Adaptative behaviour at home: for example, when at home alone, the system could push mobile notifications to home notification system (see below).
Notifications
- Expose available notification channels in a room,
- Take into location of the users, and number of users at home (or outside),
- Take into account ongoing activity (for example watching a movie)
- Connect with cloud brick to get reminders from calendars, Google lists, Alexa tasks and many more, and
- Determines automatically the smartest method to notify users
- Support light blincking or color, TTS, OSD to Kodi, toast to PC, multimedia features (TV, audio), push to mobile, email, alarm bells,
- Prioritize and plan notifications to make them smart.
Lighting :
- Light scenario by grouping (cascade, sequence, timed: see the concepts I proposed)
- Light actuators or with timelined lighting scenarios,
- Automatic lighting (when door open, at night),
- Autoturning off light,
- Expose color bulbs available to the notifications brick and provide interface for notification brick
Energy management: the Energy Meter binding measures consumption. This is a start, but the brick should be capable of optimizing energy with following behaviors :
- handle opening/closing of blinds depending on sun exposure, heat transfer of windows or any other relevant parameter
- improve start/stop of heating and cooling devices based on data collected by sensors (temperature slopes).
- Handle groups of devices that are turned off automatically depending on user presence reported by the access management brick.
Multimedia:
- Links and control audio/video devices all together to provide a simple control over the systems (no more remote like at home)
- Expose only activities available per room and have OH to interact with them (multiroom, TTS, OSD, centralize multimedia library)
Air/heating control:
- Integrate and interoperate heating control systems (Tado, Nest…).
- For example, I could use Tado to control the boiler and combine it with a home-made controller (sensors + valves) to regulate some rooms. At the end, this brick would both integrate the “standard commercial systems” and custom heating control brick and expose this in standard way.
- Provide venting regulation algorithms for humid rooms and algorithms for monitoring heating
- Interface with energy management brick
Watering:
- scheduling of watering, zones,
- suspend watering when in the garden, optimize watering hours to reduce evaporation
- Adapt watering quantity to weather conditions and forecast
- Suspend robot-mower when watering
Home appliance control:
t* his brick can handle plenty of functionalities. To name most common:
- notify when washing-machine has finished (either with a Wifi smart appliance or with a power consumption plug,
- notify when fridge doors were left open,
- notify when oven has finished.
- Start devices on schedule : for example coffee machine right before the wake-up alarm, start vacuum cleaner robot when not at home
Alarm:
- alarm covers access alarm, fire alarm (based on available sensors), flooding alarms or any type of alarm depending on sensors installed.
- take into accound user presence to adapt automatically the alarm status (using the access brick to authentify users),
- notify users using the notification brick
Mobile and cloud interoperability:
- grab, use and expose user data (calendars, contacts, lists, weather…) at the right moment and at the right place.
For example, remind me the shopping list, the traffic warnings and trash schedule when I am leaving home, use my contacts to push a phone call to the OSD using the notification brick…
Privacy: you are talking about privacy of OH user. I am talking about a logic to ensure privacy control over the house.
Should I have access to cameras currently playing media from outside and track what people at home are doing? How is this controlled (notify user at home to grant access), allow a “ghost mode”.
I am currently shocked to be able to locate my mate using the location screen in Tado or to access the listening history in Alexa. Privacy is a difficult but important topic.
Interfaces:
a brick to suggest the best UIs scenarios and methods to interact with the house : giant touchscreen were great in Minority Report or in Iron Man but are an ergonomical nonsense.
Voice control is convenient for light control or device control. Extend wall-switches usage, user-friendly panels or apps.
Action-less interfaces: how to get rid of interfaces to improve ergonomy and have the system anticipate your needs based on the context
As you can see, my concern is not about the bindings and features in OH: they are great, and allow integrating a wide range of hardware.
My point is OH to provide several “standard arrangements of bindings” under the form of a frameworks or bricks to to serve home the automation behaviors listed above. With such a logic, unskilled people can find howto’s guidelines to setup the functionality they need and reduce the need for scripting. The bricks should interfaced in a standard way also which would expose the “features provided by the brick” (scenarios), the inputs/outputs expected by the brick to work (connectors, kind of meta-bindings), and the possible interactions between bricks
Today, we are all writing and rewriting similar scripting logic in DSL or JSR. The bricks framework would provide the behaviors already coded in an existing scripting language and if possible . And anyone could choose either to deploy and use the bricks features out of the box or to customize the brick 's code to implement different behaviors.