Not getting 1-wire data

[AlbuquTurkey]

I'm very new to this programing side of HS. I installed an xAP Hub and xAPWeather and xAPNews along with xAP 1Wire and the HS xAPconduit. I'm getting data from weather and news. I can see that HS see that 1Wire exists but I can not get the IDnumber or temperture off the iButton on the reader. The 1-wire IO screen shows the button is there but I can not see the data in HS. The wizard kicked in and has assigned 3 HS units.

How do I do I get the data from the 1-wire system? If I need to send or receive information with the BSC schema I will need help or a web site to help with my first attempt at that.

[Michael McSharry]

xapmcs1Wire delivers its data in xapBSC format. It is my understanding that the posted xap plugin will recognize this schema. It includes the optional DisplayText key and extended Database key. I do not think the xap plugin knows what to do with them, but it should ignore them. You can also just remove them on the xapmcs1wire setup screen by deselecting the checkboxes for these two keys. If your only destination is xap plugin then no need to transmit data that will by trashcanned.

[AlbuquTurkey]

Still don't get the values

Sorry I'm not getting it...
I have the axp Conduit stating
Device mcs.onewire.lealbr2800 is unknown

Try updating schema or use raw mode

In raw mode I get three items to select

mcs.onewire.lealbr2800 Homeseer Event Event.Log data
mcs.one.... ...ent.Log time
mcs.one.... ...ent.Log type

When I create these I get in Homeseer three devices.

HS device Status

Using xAP port 32768
2/2/5 4:14:26 PM
mcsXap1wire

How do I get the iButton data that is attached to this?

[Michael McSharry]

I dont use the State key so I overlooked that it was not processed correctly. I dont know it this causes problems with the xap plugin or not. I posted the update V 1.1.3. Below is a message that I captured from my xap network to provide a reference as to what to expect. I do not use the xap plugin that is posted so I'm not familiar with its operation.

xap-header
{
v=12
hop=1
uid=FF000512
class=xAPBSC.info
source=mcs.OneWire.MCS6:COM4.CD000800468B8B10.Temperature
}
input.state
{
state=OFF
displaytext= html stuff that does not display correctly on posting
database=True
stream=48.2
}

[turner228]

Michael

I am not a xAP expert, nor one of the core xAP developers, but there is no mention of a "Database" key in the BSC 1.3 spec, so this is possibly part of the confusion and may cause the plugin wizard not to recognise it as a BSC device.

see http://downloads.xapautomation.org/documents/BSCv13.pdf

I know that the current version of the plugin does conform to this spec and implement all the mandatory components, but does not implement the optional "displaytext" key (see http://board.homeseer.com/showthread.php?t=101483)

Kevin

[bruce l]

I think Xap spec says if you don't understand a key then ignore it.

[turner228]

Bruce

I understand where you are coming from but the BSC is quite specific. There is no mention of a database keyword

My understanding of these specs and schema is that they are agreed by the xAP developers and that they can be developed and extended, but that it is important to do it in a way which does not break existing applications.

This might be by developing a specific schema for a particular circumstance or hardware or by extending an existing schema with optional sections in the message

What I am trying to say, but gently, is that if you create a private extension to a published specification that others are also developing to, you can hardly be surprised that your extension is not supported by the applications that are written to the specification.

That surely is just common sense

Kevin

[AlbuquTurkey]

Still Lost

I must be missing something very basic. I feel as though I understand the basics of what is going on with xAP. But in the attempt to get OneWire temperature data back to Homeseer I'm missing something. It appears that others have done this. I can get canned programs to work like the xAPWeather and xAPNews but requesting data from this OneWire has got me.
Am I trying to do it with the wrong applications?
How are you getting the data from the onewire temperature button to Homeseer?

I can see the ID numbers of the temperature buttons on xAPOneWire IO Screen but I'm not getting that information to HS. How do I get that ID number over to Homeseer?

Once I get that information to HS how do I call for the current temperature at that unit?

[Michael McSharry]

I went back and looked at xapBSC schema again and see that a stream of characters do not use the key "stream", but the key "text". I'll make this change and repost as 1.1.4.

I suspect this may be what is causing the xap plugin some difficulty. It still, however, should create a virtual device and populate the deviceStatus with the value of the "state" key.

The rules of the xap game are just like the rules of the spoken language. If someone speaks a word that the listener does not understand then that aspect of the communication was not successful, but other elements of the sentence can still convey information.

Additional keys to existing schema can be added with the requirement placed upon the listener to ignore any key they do not understand. As new keys gain acceptance and become part of the normal dialog then they will migrate to optional status within the schema definition (i.e. they will be added to webster's dictionary).

In the case of mcsxap1wire, the user configures which keys they want xapmcs1Wire to transmit. The required key "state", the optional key "displaytext", and the extended key "database" are all configurable by the application. For my environment I have no use for state=ON when taking a temperature reading so I normally configure it out of the message. If in the future I run an xap application that depends upon this key then I will configure to add it back in. I have alot of xap traffic so I try not to transmit things for which there is no listener.

For a spec-compliant xapBSC listener the message should be discarded if the body's "state" key is missing or contains an invalid value. It should also discard the message if the header is not in good form. Beyond that nothing is expected of a compliant listener.

The message posted above "mcs.onewire.lealbr2800" contains only the address porting of the source to identify it came from the computer with the name lealbr2800. The subadress components (after the describe the actual sensor with the format "InterfacePort.SensorSerialNumber.SensorType". This subaddress will correlate to an index that is contained in the message header. In my message that I posted the index was 12 as shown by the last 2 digits of the UID in the header. "COM4.CD000800468B8B10.Temperature" is its name and 12 is its index with a one-to-one relationship between the two.

I would expect the xap plugin to create a virtual device at some device code and default its name to "FF000512", "COM4.CD000800468B8B10.Temperature" or "mcs.onewire.lealbr2800.COM4.CD000800468B8B10.Temperatur e". It should accept the "stream" key value and put it in either the deviceValue or deviceString of this newly-created device. I put the "stream" into the deviceValue and "DisplayText" into the deviceString in my xap plugin implementation.

[AlbuquTurkey]

Sounds good:

I understand what your saying now let's see if I can implement it. I will attempt it in about 2 hours when I get home. Thanks for the help. If I can get this one running I'm sure that I will understand the xAP communications. I don't usually have this a hard time understanding and getting new things to operate.

The three virtual devices that HS did create have
Using xAP port 32768
2/2/5 4:14:26 PM
mcs.OneWire.lealbr2800

My UID is FF000500
My sensor number lets say is !@#$%^&*()
and it is on COM2

Would my call be
{
v=00 (this is your 12?)
hop=1 (this is ?)
uid=FF000500
class=xAPBSC.info
source=mcs.OneWire.lealbr2800:COM2.!@#$%^&*().Temperature
}
input.state
{
state=OFF
displaytext= (to be figured out but it is just putting text into a device state)
database=True
stream=48.2 (this is ?)
}

and were do I put this?

[Michael McSharry]

There is nothing that you should have to do. It is totally transparent to you when all is working properly. xapmcs1Wire will send an xapBSC message and the xap plugin will understand it, create a virtual device for each one, and then you can do things in homeseer with this devices. I don't know which properties of the device that James's plugin will populate. I'm guessing he is populating the DeviceStatus from the "state" key, and DeviceString from the "text" key. This is something he or someone else will need to answer.

The following discussion is assuming you are just trying to understand the structure of the message. There is nothing that you actually need to send or interpret on reception.

My UID is FF000500 ...

This is only the UID for the heartbeat. The sensors will have a UID of FF000501 through FF0005FF and will likely be FF000501, 06, 0C for three temperature sensors.


My sensor number lets say is !@#$%^&*()
and it is on COM2

Would my call be
{
v=00 (this is your 12?)
hop=1 (this is ?)
uid=FF000500
class=xAPBSC.info
source=mcs.OneWire.lealbr2800:COM2.!@#$%^&*().Temperature


Almost correct. There is no call to be made. The v=12 is version of the xap spec and is purely a coincidence that it is the 12 that was part of my FF000512. Hop is used when propogating network bridges so it will always be 1. Your first sensor will be...

{
v=12
hop=1
uid=FF000501
class=xAPBSC.info
source=mcs.OneWire.lealbr2800:COM2.!@#$%^&*().Temperature


The second one will have the UID and .!@#$%^&*(). changed to FF000506 and ._)(*)_*()(*). It is 506 rather than 502 because some devices report multiple things such as a DS2438 that reports both Humidity, Temperature, and raw analog voltage. I think I allocated 5 digits for each sensor and this was strickly an implementation decision on my part. For the xap version of TEMP05 I allocated a smaller number because fewer options per sensor are provided by the TEMP05 than by DS9097.



input.state
{
state=OFF
displaytext= (to be figured out but it is just putting text into a device state)
database=True
stream=48.2 (this is ?)
}

and were do I put this?


The "stream" has been changed to "text" in V1.1.4. The 48.2 is the temperature reading formatted in pure ascii without degree symbol or C/F units appended.
The "database" key should be configured-out from the message on the xapmcs1Wire setup screen. Only my applications know what to do with it. In your setup it will just be stuff on the LAN that no listener will understand.
The "displaytext" also can be configured-out at this time since James' xap plugin does not know what to do with it. Since it made it into the schema when BSC went from 1.2 to 1.3 then there is a chance that this xap plugin will eventually be updated to process this key.
Like mentioned before, you do not need to put this anywhere as message protocol is an application-to-application communication. It would be like asking how to format the header of an HTTP transfer. While the format is no secret, it it transparent to someone who uses Browser.

[CouchPotatoe]

Michael

I am not a xAP expert, nor one of the core xAP developers, but there is no mention of a "Database" key in the BSC 1.3 spec, so this is possibly part of the confusion and may cause the plugin wizard not to recognise it as a BSC device.
Kevin

Indeed there isn't but the BSC spec should be recognised from the class name of xAPBSC and the section names. There is a general xAP policy that any content you dont understand should be 'gracefully' ignored so this shouldn't confuse anything.

Yes, you can add whatever keys of your own you wish - ideally you should do this by using a separate secondary body section but it can be done in the main body too. The only thing you should be wary of is the choice of parameter key value name. If you choose something common like Value= or Type= then there is a chance that later such a ketword will become reserved and added to the schema spec and then you might conflict - although it is more likely we will move to using a deeper schema class hierarchy to show some level of inheritance of earlier standard schema.

Kevin

[Michael McSharry]

AlbuquTurkey,

Did you ever evaluate the 1.1.4 version with the stream key changed to text?
Did you look in the xap plugin documentation to see if the expected format is described?
Did you try to contact James via his web site or private message? We are all just guessing and he is the one that knows best how his plugin works.

[AlbuquTurkey]

Got it working (kinda)

I work at Dallas Semi. and the temperature sensors that I've got are not main stream. So over the weekend I pulled out the old weather station and plugged it into the computer. Everything worked. When I went back to the temperature sensors iButton system it didn't work.

My question to you is:
Is there a way the I could get your xAP 1-wire to send all the ID numbers it sees out accross the network. Assign it Temperarture, Humidity ... if you know what it is but if not just send out a change notice. ie. Send ID# removed from system / ID# added to system if funtion is not known.
Then later add a command that I could send back that that ID# is a Temperature sensor, humidity sensor... or to use only the ID number. This way we could use the 1-wire for access control as well.

Sorry for the run around on trying to get the 1-wire to work. I didn't even think about the fact that you would be looking at the DS part number but it makes good since to do that.

[Michael McSharry]

It is possible for me to deliver the 16 character address. But the manipulation of this device to get a reading is not just as simple and the user saying they want it to be a humidity sensor or counter, or relay, or anything else. Each devie family has specific ways to goose it to make it do something reasonalbe. I have implemented the code for the device families that users have had an occassion to use. If you let me know the family code (last 2 characters of the 16 character id) then I can assess the code necessary to make it play. I will put the "Unknown" type in the next update so you can at least see what is connected.