RS1xx provide timestamp

[davorin]

EHLO (o;

I have received some Laird RS1xx nodes…and their documentation says that it will remain in state activation until an uplink message with empty payload receives a timestamp in epoch format.

How do you provide such a timestamp if you use the HTTP integration?
Just do a POST to the supplied downlink URL with an array element called “timestamp” ?

Or does the RS1xx needs a special format?

Edit: This doesn’t seem to work…sending timestamp as payload_raw:

{“dev_id”:“me-home-rs1xx-1”,“payload_raw”:“MTUyOTE1NDM4Ng==”}

After doing a single POST to the supplied downlink URL, the downlink message is sent endlessly to the node.

thanks in advance
richard

[davorin]

Okay…got it now (o;

You need to send it base64 encoded as payload_raw…not as timestamp but with the RTC format the RS1xx expects…sample PHP code to generate it (keep it simple and stupid style ;o):

<?php

	// Laird RS1xx RTC Message Format
	// 0x02 0x00 0xYY 0xMM 0xDD 0xHH 0xMM 0xSS
	date_default_timezone_set("Europe/Zurich");

	$year = intval(date("y"));
	$month = intval(date("n"));
	$day = intval(date("j"));
	$hour = intval(date("G"));
	$minute = intval(date("i"));
	$second = intval(date("s"));

	$message = $second + ($minute << 8) + ($hour << 16) + ($day << 24) + ($month << 32) + ($year << 40) + (2 << 56);

	$hex = dechex($message);
	echo $hex . "\n";
	echo base64_encode(hex2bin("0" . $hex)) . "\n";
?>

[kersing (Jac Kersing)]

Did you check the amount of downlinks used by the devices? When I tested months ago the device used a downlink for each uplink which is at odds with the TTN fair access policy.

[davorin]

I know of the fact that the RS1xx send each uplink message with a confirmation request…with latest firmware…

Haven’t found anything in the node settings nor in the LoRa protocol docs of Laird how to influence or stop this…

But the node runs on my own gateway here…and nothing else here is connect here out in the sticks (o;

Dunno if those nodes can be programmed as the RM1xx modules to run an own firmware…

Did you experiment with the RM1xx modules as well?

[Jeff-UK]

These units are currently essentially fixed function driven by an original development programme requirement, short of opening up (they are glue sealed) and hacking the hardware there isn’t any easy way to re-purpose. I understand some early release software is in development and due to be demoed that will allow more flexibility, and re-programming capabilities and hence opportunity to eliminate (or significantly reduce) confirmed download requirements, but that seems to be some way of public release status as yet. I’m hoping to see as soon as ready for release and will advise if/when I see it…

Also FYI from what I could see based on quick limited tests (Am open/hoping to be proved wrong!) ‘anyone’ who pulls the android/BT management app to manage these devices & who gets close enough that they can see a given device over BT is basically able to ‘pair’ & change device settings and potentially hi-jack or sabotage set-up!..am still investigating and looking at more secure options, as was hoping to use a bunch on a pending project…actually a ‘nice’ product

Security by obscurity might be option for you if out in the sticks as you say

[davorin]

Interesting that hard/Software is that closed…especially when their site advertises it as:

“with precise temperature and humidity sensors, and room for future expansions”

[Jeff-UK]

FYI I recently met with Laird to discuss options & suggest features and a series of updates are indeed pending…Laird will phase in new features/options capabilities over next few weeks and summer. 1st new release (before end of month?) will make confirmed uplinks optional & remove need for an initial timestamp before sending payloads (Set up then no longer needs e.g supporting Node-Red instance to hand timestamp). Also looks like they will make a release with Cayenne LPP format an option - I expect in 2nd or 3rd update to follow

Comment back on another thread

dbrgn

with Cayenne LPP format

Unfortunately Cayenne LPP is severely underspecified and will result in different incompatible implementations Maybe someone should create a better specification of a format like that. (I already thought about starting something…)

But that’s offtopic.

My response and call to action re payloads?:-

Agreed but its a good start - Cayenne seems v popular with TTNers and well understood so me thinks pat on the back to Laird if they do go that way as option. Indeed in recent meet question was asked what other payload/standards might be desired/supported so if folks have a view let me know and I will try to co-ordinate a response/feedback to Laird prod management & eng/firmware teams…

…off topic as you say…

So anyone reading this thread with ideas for desired payload standards please shout!..

[Jeff-UK]

To UPDATE: Last week I received a draft release (awating final sign off and release) of new f/w build, new/updated Smart-Phone management app (android .apk) and draft Application Note covering device integration with Cayenne. It came in whilst on vac and doing overseas LoRa trials so no immediate chance to test and evaluate but from what I can see new phone app allows user to choose Laird or Cayenne payload format and to choose confirm payload or not acknowledge payload delivery.

Will need to play in next few days to see if timestamp still needed to initiate payload deliveries (I dont believe it is… ).

Laird team working hard to get all to released status, signed off and pushed out to user base…will update here when I hear its ready to go

[Jeff-UK]

To UPDATE:

Happy to confirm new app installed fine on spare phone and then allowed option to download the test release f/w that enabled the new options.

Running in Laird payload format the ‘confirmed’ option is on and greyed out - looks like you have to use ack with Laird version (at least for now). (see earlier packets in image below). Then switched payload format using the app to enable Cayenne vs Laird and confirmed no longer greyed out and can chose either confirmed or unconfirmed - later packets in image show Cayenne format and unconfirmed

Better yet the payloads are coming through without having to set up a (e.g. Node-RED) server to send an initial timestamp before the payloads start rolling in…

Now a happy geek and next steps set up Cayenne integration per draft App Note

Will update on progress in coming days…

[kersing (Jac Kersing)]

Excellent news. Hopefully this version will be released soon.

[nheinrich]

Thanks everyone for sharing knowledge here!

I ran into this today after picking up my first LoRa devices (Laird Gateway and Sensor) and haven’t been able to get this to work. I was following the example provided by @davorin and wasn’t able to start receiving data. I ran the code in php, ended up with a payload and passed the following json object via downlink:

{"dev_id":"rs191-sensor","payload_raw":"AgASCBACFyY="}

Unfortunately, I ended up in the same place he initially did. It sends the payload down every time an uplink comes in and I never actually get the sensor to send useful data back to me. I ended up deleting my device (in TTN) and setting it back up to get rid of the constant downlinks.

Thanks!

[PiSupply]

@Jeff-UK are you able to share this new FW / app or not until it is officially released?

[Jeff-UK]

Hummm…thought it would be out by now - will check status though my contacts and see what can be done.

[crmrosa (Claudio Rosa)]

I am having the same problem with my RS191, “payload: [not provided]”. The firmware version available is V3.2 and it don´t have no payload format option.

Any news about the release date or any roadmap? I mean Octuber, 18 and no news

[Jeff-UK]

I understand there is an imminent code/release review (expected to be final) so fingers crossed we see something new for general use in days/next week?!

[PiSupply]

Awesome. Looking forward to that

[shawaj]

FYI this is now working using the 18/10/18 test firmware update v4.4 and the latest version of the app