Problem with message

[tonlof]

I am using owfs on linux with xpl, I can see all package in windows xap-xpl hub. The strange thing in the images is the status info change all the time from all sensors and it change very fast on same HS device.

I have over 20 1wire devices that flash in hub.
It does not create devices in admin for each xap-device only 3 heartbeat and 3 sensor, CURRENT, TYPE, DEVICE
I think the xap-xpl message is different, any suggestions.
Thanks

[Michael McSharry]

The issue is that you would like to have the DeviceID to be part of the address that uniquely identifies the message rather than as a property of the Sensor.Basic message. Let me see if it could be handled like the xap-x10 schema that also does the same thing.

[Michael McSharry]

I added translation logic for sensor.basic to xapbsc.event in the attached. I do not have an xpl environment for testing and it has been many years since the xpl part of the hub has been touched. You should expect each sensor.basic message to be delivered to one hs device. If you have an issue then some debug can be added.

[tonlof]

I added translation logic for sensor.basic to xapbsc.event in the attached. I do not have an xpl environment for testing and it has been many years since the xpl part of the hub has been touched. You should expect each sensor.basic message to be delivered to one hs device. If you have an issue then some debug can be added.

Many thanks Michael.
It's working much better now.

I found this in log. (Reapeating)
2012-01-08 12:05:09 - mcs.hub.HS-SERVER>x - tohex 1 line 20 type mismatch
2012-01-08 12:05:09 - mcs.hub.HS-SERVER>x - tohex 2 line 20 type mismatch
2012-01-08 12:05:09 - mcs.hub.HS-SERVER>x - tohex 3 line 20 type mismatch
2012-01-08 12:05:10 - mcs.hub.HS-SERVER>x - tohex 4 line 20 type mismatch
2012-01-08 12:05:10 - mcs.hub.HS-SERVER>x - tohex 5 line 20 type mismatch
2012-01-08 12:05:11 - mcs.hub.HS-SERVER>x - tohex 6 line 20 type mismatch
2012-01-08 12:05:11 - mcs.hub.HS-SERVER>x - tohex 7 line 20 type mismatch
2012-01-08 12:05:11 - mcs.hub.HS-SERVER>x - tohex 8 line 20 type mismatch
2012-01-08 12:05:11 - mcs.hub.HS-SERVER>x - tohex 9 line 20 type mismatch

[Michael McSharry]

I attached an update that does two things. One is it should correct the errors you were seeing and the other is that a debug in the xpl translation was added as a checkbox option. When enabled it will log the XPL messages and their translation to xAP schema. If you do any checkbox changes then you need to close the form to have them enabled. You can open the form again if you like.

The mapping of the xapbsc.event message data into HS is dependent upon how to define the structure in mcsXap of what field goes to what HS property. Likely you have defined something that is different than the default and what I use so the HS properties are not populated as desired upon Acceptance. You can edit these properties within HS to be whatever you want. For example, the Type can be changed from the serial number to Temp or the name changed from the UID to a more descriptive one.

If you have propblems with the translation then enable the debug/Logging described above.

[CouchPotatoe]

Sub Addressing in xAP

Just as a bit of background...

In the xAP header Source= parameter we have an address and an (optional) sub address separated by a : The address represents the whole device and the sub address is used for all it's endpoints e.g. in your case the attached 1-wire sensors. Hence in xAP we can associate every endpoint with the parent device and importantly all this information is in the message header.

xPL does not have sub addresses and so instead has to include this information within the body mixing data values with the endpoint identifiers. This can be quite confusing and is difficult to parse automatically for new schema as you are unsure which parameters are data and which are identifiers. Hence you need to have special handlers for each schema (as Michael has done for you with this one).

In the very early days of xAP , before we added sub addressing some xAP schema operated this way too - the X10 schema being one of them. Nowadays it is strongly discouraged to avoid exactly this issue. The X10 connector was rewritten using the xAPBSC schema, as sub addressing is the way to go.

K