This page last changed on Jun 18, 2012 by tkucharski.

Hi guys,
I built my home automation system based on 1-wire devices. As a result I have about ~20xDS2408 working as digital inputs (160inputs), 20xDS2408 working as 10A 240V power output (160output) and approximately ~30 temperature sensors. I've got custom made solution supporting switches, humidity, temperatures and inputs. Logic is defined in drools.
I've noticed openremote supports rule engine finally, so it's good reason to redesign my solution and merge it with OpenRemote

OpenRemote supports OneWire (thanks to Jaroslav Misura commitment) but is very limited:

  • doesn't support alarming
  • do not support device latch attributes (quite necessary in switches)
  • poorly optimized 1-wire requests (needs 1 requests per device, not command)

Looking at svn stats I see active commits made year ago. I would like to contribute to openremote but needs more information about controller's protocol interface and design.

  • is it possible to introduce new device type with custom properties?
  • Are there any rules related to introducing new device type (i.e Russound device vs Device)?
  • Is an "ordinary" device just a grouping element in UI designer?
  • Is there any device lifecycle? Especially initial call executed as a phase of starting openremote controller.
  • Are there any constraints to thread management? Is it consistent with architecture to provide 1-wire protocol connector with dedicated thread scanning alarming devices?

diagram.png (image/png)
onewire-structure.png (image/png)

Hi Tom,

the code was already changed to reflect our latest architecture which supports EventListener. This means that the command is responseable for listening/polling the latest status of your device and updates the sensor.

I also added support for an extra attribute "data" which can be used for switches to send "1" or "0" to turn on/off the device.
The latest code can be found here: http://openremote.svn.sourceforge.net/viewvc/openremote/workspace/mredeker/Controller_2_0_0_Fixes/src/org/openremote/controller/protocol/onewire/

What are device latch attributes and commands?
We are using the Java jowfsclient library which connects to owserver from the owfs project

Posted by mredeker at Jun 19, 2012 13:34

Hi Marcus,
I know this new feature (found on the forum) and deployed fixed version.
I see you did really good job providing 1-wire adapter to OpenRemote, but there are still several obstacles that (in my opinion) needs to be removed to use 1-wire effectively.

Initial commands

There is a need to run "initial commands" to set up alarming feature. These commands include:

  • set_alarm with parameters described on owfs page. Usually it would be 133333333 for input switch device (DS2408)
  • turn off por flag (power on reset) to eliminate artificial conditional search results

It should be run once (running it on every single request is just inefficient)

String command = "set_alarm";
String parameters = "133333333";
client.write(path + SLASH + command, parameters);

String command = "por";
String parameters = "0";
client.write(path + SLASH + command, parameters);

Using latches

There is possiblity in OpenRemote to read from "LATCH.ALL" instead of sensed.X command. This is crucial to handle input made between openremote calls to owfs. There is an issue with this approach - you need to reset these latches after reading it.

private static final String LATCH_ALL = "latch.ALL";

public void read() throws NetworkException {
   String s = networkConnector.read(LATCH_ALL);
   // handling goes here
   latchReset();
}

private void latchReset() throws NetworkException {
   networkConnector.write(LATCH_ALL, LATCH_RESET);
}

OpenRemote->OneWire request's efficiency

Creating command for every single input in i.e. DS2408 (has 8 of them) is inefficient. I haven't performed any performance tests with openremote's 1-wire adapter, but I almost sure it would scale up to 5-10 devices. Reading more than 10 commands results in ~200ms lag that is quite annoying. Currently working implementation in my house (quite simple, based on jowsfclient as it is done in OR) consists of requesting "latch.ALL" attribute on alarming device.
There is no doubt that request's efficiency has minor priority as it is not essential for <10 onewire devices installations.
Although it is crucial for me, I think it can be discussed later

Posted by tkucharski at Jun 20, 2012 02:31

Looks like it all drills down to some read and write actions which is already doable.

We don't have a "initialize something" method yet but to test you could just create the appropriate command and trigger it only once with a button press. I will discuss this feature with the others.

If you crate a "latch.ALL" command you can assign a custom sensor and parse the string within the rules engine to update multiple sensors. That rule could also trigger a command which executes the latch reset. This is just an idea and I cannot test since I only have temp and humidity 1-wire devices.

Posted by mredeker at Jun 20, 2012 08:50

Hi there

It's been a long time since my last post, but I decided to share my experience with OpenRemote 1-wire support.
I tried to use existing 1-wire protocol adapter but this code was designed to support passive devices (like temperatures and humidity sensors) and simple switch device.

I needed more advanced support for switching devices. Both switches (>160) and relays(>160) are utilizing DS2408 devices.
As turning light on after clicking switch has to be instant there was necessity to utilize 1-wire alarming feature and more advanced multithreading.
I followed Marcus Redeker suggestion to create command for every switch but lack of alarming functionality and switches support made it both hard to configure and completely unresponsive.

I developed new version of 1-wire support in OpenRemote that uses alarming events introduced in new jowfsclient library. It introduces alarming and switching type of command at the same time providing backward compatibility for INTERVAL and PASSIVE commands.

It works perfectly for almost half a year in "production environment" withot any issue.
I would like to push it into OpenRemote codebase if you guys agree.

You will find some info regarding onewire adapter If you are interested in how it was done. Hope it helps to decide whether to push it to repo or not.

Package structure

This diagram shows relationships between different command types

This is the code snippet showing commands type available in one wire protocol.

/**
 * Represents types of commands supported by OneWire adapter
 * @author Tom Kucharski <kucharski.tom@gmail.com>
 * @since 14.04.13 18:53
 */
public enum OneWireCommandType {
	/**
	 * Devices that alerts on 1-wire alarm
	 */
	ALARMING,

	/**
	 * Switchable devices, mostly used in DS2408 or in similar devices;
	 */
	SWITCHABLE,

	/**
	 * Simple command that reads its value periodically
	 */
	INTERVAL,

	/**
	 * Simple passive command
	 */
	EXECUTABLE;

}
Posted by tkucharski at Oct 13, 2013 00:09

Hi Tom,
this sounds great. We would appreciate if you want to contribute your code.
Please take a look here: New Contributors Getting Started

Posted by mredeker at Oct 13, 2013 19:13

Thanks Marcus,
I've just send you an email to add my user account to OpenRemote repository.

Posted by tkucharski at Oct 13, 2013 22:17

Hi Tom,

Your solution looks really interesting, as I'm looking at implementing control and sensing using the DS2408.

Has your code been accepted into the codebase? Is there any way to get access to the functionality?

Posted by c973535 at Nov 09, 2013 11:45

Hi Anders,

My code has been accepted into the codebase but it is still on feature branch. You can check it out here: https://svn.code.sf.net/p/openremote/code/workspace/tkucharski/Controller_2_1_0_FM_20130617_OneWire

1-wire adapter was rewritten from scratch as there was required to support devices other than simple and passive temperature sensors (DS1820).
New implementation is backward compatible, but introduced features such as:

  • support alarming devices (actually it is only DS2408)
  • dynamicValue parameter enabling to send command data via rules.
  • shared device property value between different OpenRemote commands
  • global onewire configuration in designer that makes introducing new devices with less hassle (currently available via https://composer.openremote.org/staging only)

New features and configuration examples will be described here: http://www.openremote.org/display/docs/OpenRemote+2.2+How+To+-+1-Wire+Sensors

How are you going to use DS2408? Will it be used as relays controller or as 8-channel input sensor?

Posted by tkucharski at Nov 10, 2013 23:32

Hi Tom,

Thank you for replying, the link especially to the documentation you updated helped my understanding of the possibilities with the new code, and it is still aligned with my plans.

I'm still quite new to OR, which means I am spending quite a lot of time reading and searching around the forums for tips and how to's, and at the same time trying out the basic steps of OR in order to determine my design possibilities.

My setup is remote control of a holiday house on a budget (raspberry pi,I2C->1-wire, 3G USB, inexpensive 1-wire components). The house is fairly new, and I managed to install quite a few twisted pair cables around the house during construction, as well as magnetic sensors in the windows and doors, with the aim/hope of a home automation project later on.

My intention is to use the DS2408 both as sensors, reading the window and door sensors for break-ins, as well as relays controllers, for remote heat control. Which is similar to your setup, as I understand it, although my setup is smaller, approx. 10-15 relays and 15 access sensors + some temperature sensors. The features you have implemented are therefore spot on.

As I said I'm still in the early phases, still a bit of learning curve to overcome, but I'm differently trying out your implementation so I will probably be back later with more questions

Thanks for pointing me in the right direction.

Posted by c973535 at Nov 11, 2013 19:15

Anders,
Good luck with your installation.
Do not hesitate to ask me if you've experienced any difficulties in configuring OR.

Posted by tkucharski at Nov 12, 2013 12:50
Document generated by Confluence on Jun 05, 2016 09:30