subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
304 views 2 comments
by anonymous

what is the new official way of setting an output from CLI? doesn't work anymore. There's a documentation in, but only for reading inputs and outputs. What's the method to call for setting an output?

1 Answer

0 votes
by anonymous
Ok, totally accidently I found it here:

The wiki page for a different device!

Is it that hard to make a full documenation of Your products? Do the users have all the time find out by themselves stuff, that You manufacturer owe them to tell!? Sometimes 3rd party sources give better information than the manufacturer. This is not professional, nor "industrial".

That's obviously the tactics: save money/ressources on the documentation, leave the users to post the questions in the forum and let some other users (or like in this case the same user) do the work and answer.
by anonymous
ok, cool...
I've been playing whack-a-mole on this 955 IO thing

I noticed, based on your TRB141 documentation that

ubus call ioman.gpio.dout1 status does indeed run, and return a pile of values
whatever happened to 1 or 0 ?

however, suspicions arise when I notice that checking din1 and din2 produce different results

one is on the other off - plus they don't correlate with the values shown in the webUI which are both 0

so then I look at changing the output status of dout1

ubus call ioman.gpio.dout1 update '{"value":"1"}'
YIKES!! what's with all the hoo-fricken-hah!!??
how about update 1
friggen government committee worked on this ?  14 character hyper-verbose overhead ?
OK, I get that maybe one can update the configuration simultaneously but I would consider that
a bit sketchy to combine ordinary state change with config in the same message

Anyway, while that command does indeed not throw any errors, or piston rods, it doesn't actually affect the actual IO status.

I thought, OK, I'm going to confirm my bias that the WebUI is probably showing the real goods, and indeed it is...
inputs change when wires are applied/removed and changing relay state makes an audible click and zero-ohms

so, I'm a bit closer-ish, but still no worky
I think that it is not unreasonable to expect syntactic consistency across the product line for equivalent function
by anonymous

poking around a bit more, I discovered that the relay works on the 955 using:
ubus call ioman.relay.relay0 update '{"state":"open"}'


ubus call ioman.relay.relay0 update '{"state":"closed"}'

I also discovered that my previous testing has been in error due to a wrong presumption
on my part...
I presumed that din1 and dout1 would be the IO on the  10pin IO of the 955
and it turns out that they are actually the IO of the 4-pin connector.
When compared correctly to the WebUI, and wire-wiggling and relay clicking,
everything is working as it ought...