I am testing this on a hap lite running Ros 6.49.17.
The idea is to have something that can flip/toggle the status of the user led (the ONLY programmable led on hap lite) at each run.
For the moment I am using it as the script connected to Mode button, so at each press of the mode button the user led is triggered at the opposite state it is: The script in human readable format:
and in the export format:
It works just fine .

Questions:
1. is it "correct"? (as is it works, but to be picky the else condition should probably be "narrowed" to another conditional check, and I am also not too sure about the various brackets)
2. can it be simplified? (the detection method with len of the find with two conditions seems to me a bit over-complicated)
3. is there a way in Ros command to "flip" a value 0/1 (or yes/no or in this case on/off)?
4. besides the above doubts, better ways/ideas?

Bump #1.

1) If work, is correct and is not too much complicated.
2) See my example.
3) Can be one-line command if accepts true/false (boolean) instead of on/off...
4) Missing a chech if the leds group exist. On my example I add it if is missing (but I do not check hardware if have or not the led)

If is something that at the end must power off or on the wifi and user-led show the status...
viewtopic.php?f=7&t=115078&p=857648#p857648


This script invert status and create user-led if not exist (do not check if hardware have or not the led):

Thanks rextended.

The essence is the same , bummer , I hoped there was a clever way to invert the status of a boolean *somehow* without needing to check the current one with if, something loosely *like* (pseudocode):
set [find where leds="user-led"] type= NOT $currtype

The add leds would work on hardware that support it and do nothing on hardware that doesn't, right?

Is the check for <1 "better" than the check for >0 I originally had?

Is the :toarray conversion actually *needed* or it is just good practice?

[...]

The essence is the same , bummer
>>> Why " " ? It's better than... I don't want to argue with the AI ​​as usual

>>> I hoped there was a clever way to invert the status of a boolean *somehow* without needing to check the current one
Exact, can be done, but is not a boolean, is on or off. Why MikroTik choose that??? Mah...

>>>with if, something loosely *like* (pseudocode): set [find where leds="user-led"] type= NOT $currtype
yes like hypotetical if is true/false "set $uledid ![get $uledid type]"

>>The add leds would work on hardware that support it and do nothing on hardware that doesn't, right?
Not tested, as wroted, but I do not know a way to test (except for compare RB model against know list or use on-error-resume-next)

>>>Is the check for <1 "better" than the check for >0 I originally had?
In my case it means "if there isn't (at least) one add it on"
In your case it means "if you find (at least) one turned on"
The difference is that I do only one search, so I need to know if there is at least one ID inside the returned value,
in your case you do 3 separate searches.
It's a code optimization.

>>>Is the :toarray conversion actually *needed*
It is absolutely useless, but... there is always a but...
I prefer to always provide correct types to functions.
Often with the change of versions "strange" things happen (remember???...).
So since leds= expects an array, I provide it with an array, without RouterOS converting the string into an array.
Basically I do NOT increase the number of operations that must be doed, but I explicitly make a conversion that should happen inside.

>>>or it is just good practice?
I usually write scripts that make people... think... (at least I hope).
It's not a bad thing to make sure that the right variable types are used, without blindly relying on the internal conversion (which as seen, often fails).
[pratical example: in RouterOS 7.18 if the quotation marks were not put in the file name (which is a string) it gave an error]
In fact, even "on" and "off" being two strings, I enclosed them in quotation marks.

Bear in mind that often when I review my very old scripts, I'm not satisfied with them...
Over time I've learned to make them better...

yes like hypotetical if is true/false "set $uledid ![get $uledid type]"

Exactly .

in your case you do 3 separate searches.

To be picky, 2 as there is the else, but I get the point, generally speaking is better to limit the number of searches and use a variable as reference.

In the specific case of the hap lite, there is seemingly no other led accessible but user-led, so I could even remove the "user-led" reference and just look for type on or off or even (horror! ) use set 0=on/set 0=off.

While playing with the thingy, there is also the disabled state, the user-led set to on BUT disabled is actually off, and as soon as I enable it, it lights up.

At least on 6.49.17, the status change is in the log as system, info, but always with the same message (not useful) "led trigger changed by admin" , no mention of which led it is, not which change was made.

use set 0=on/set 0=off.

no... please no........

at least set [find] type="<on or off>"

While playing with the thingy, there is also the disabled state, the user-led set to on BUT disabled is actually off, and as soon as I enable it, it lights up.

muble, muble.....

Turn on/off the user-led if is already defined, obviously is always type="on"


Well, you should be satisfied, today you beat me!!!

Nice.

Anyway I don't see it as a race, or, maybe better, it is a boat race, and we are in the same boat, we'd better start rowing.

I think you misunderstood me, it was a compliment for you...
I know you didn't have the idea, but you were fundamental in intuiting the right point of view....
[What can be easy flipped as true/false? Whether it is disabled or not!]

I need some time to digest this new approach, it may become useful also for something else, no idea what yet.

If we limit the type to either on or off, we have four possible setting combos leading to the two possible states, but with ratio 1:3:
1. (disabled=no)+(type=on)=LED ON
2. (disabled=yes)+(type=on)=LED OFF
3. (disabled=yes)+(type=off)=LED OFF
4. (disabled=no)+(type=off)=LED OFF

A hypothetical "isLEDon?" script only checking whether the led is on or off needs to check for just one set of conditions, #1 above.

Then one could make the script do nothing if condition #1 is found else set the whole stuff as condition #2.

This would not alter the actual status of the led (if the led is on, it remains on, if the led is off it remains off[1]) but the settings will surely be the "right" ones for the disabled= boolean flip.

[1] if it is set to something else like -say - wireless-status too bad, I need the led to be either on or off to toggle it, so for me !on=off

Karnaugh
  Y N
O 0 1
F 0 0
disabled Yes / No
type On / oFf
LED 0=off 1=on

So the less expensive thing to consider if is at the same time disabled=no and type=on

Karnaugh

The English translation of Carnèade (Chi era costui?)


Seriously, I always thought that Karnaugh started at 4 variables and a 2x2 was simply a "truth table":
https://en.wikipedia.org/wiki/Truth_tab ... _operators

Ok, so this should be it :

(no space between do= and {)

I think this suffice... on same set you can set more...

The idea is to have something that can flip/toggle the status of the user led (the ONLY programmable led on hap lite) at each run.

I'm very curious how you will be using this.

What situation, condition, or new event do you want to monitor by way of whether the LED is on or off?

For example, if wifi interfaces are on/off.
Some customers ask me to disable wifi on cAP central button press, that also disable the led...

For example, if wifi interfaces are on/off.
Some customers ask me to disable wifi on cAP central button press, that also disable the led...

That makes sense -- a quick glance at an AP to see whether wifi is enabled.

I was hoping for something more interesting: Maybe the bathroom being available, or dinner being ready, or an important message waiting, or the room temp outside of a range....

(no space between do= and {)

Fixed.

I think this suffice... on same set you can set more...

I know, but with one set per line it seems to me more readable.
I am always thinking about the future me finding an old script and struggling to understand what (the heck) it was intended to do.

Code: Select all

/system leds find [:if ($leds=[:toarray "user-led"]) do={set $".id" type="on" disabled=(!$disabled)}]

Yes , you are right of course, this would be the definitive (as simple as possible, but not simpler ) version, but I needed to do the intermediate step to understand/test a couple of things, now that you condensed everything in a one-liner it is perfect for this simple use.

When/If I will add other commands to the mode button press (i.e. - and this is a partial reply to Josephny's question[1]) it will make sense (to me) to re-split the commands one per line.


[1] the complete answer is not yet ready, it will do such things... What they are, yet I know not, but they shall be... The terrors of the network!

@Josephny

Interesting, but the LEDs are small and you would have to have the device in front of them to attract attention...

Understand, but I am not able to read your "version"...
This?

addedndum on previous post: missing quotes between "trueon", the 2nd pair of [ ] are useless,
on $"disabled".$"type" no one quotes must be used, alternate format for not use the dot: "$disabled$type"
but I wouldn't check if it's disabled or not, which should be inverted, but if type is on or not
and at that point it goes without saying, just always set type=on....

@Josephny

Interesting, but the LEDs are small and you would have to have the device in front of them to attract attention...

Yes, makes sense.

I use Home Assistant for general integration between tech and the real world. I'm not expert at it, but Home Assistant is a great platform.

Yes, the two set can stay on a same line (after all they are part of the same set of commands), but something like this:
or this:
appear (to me) more readable.

@Josephny
Anyway, since you mentioned home assistant, I'll give you a few hints.

I am - generally speaking - cheap/thrifty, and I cannot resist some things.

I was looking for a single smallish 2.4 GHz access point, and thought that a hap lite (price new some €22+9.99 shipping) would have done nicely for my intended use, when I happened to find an e-bay offer for 4 used hap lites TC for €30 including shipping.

It goes without saying that I have now 3 unused hap lites to play with , in the worst case they can be used as "dumb" four port switch.

I made a first (failed for the moment, yet ...) attempt as a sort of network "man at work sign" (which is something that would be useful when doing maintenance), JFYI:
viewtopic.php?t=213862

Then I thought, what if I could use one of these things as a web/ethernet relay? (yes, single channel, wired, not one of those wifi thingies)

The ones you can find (possibly exception made for a few professional ones that go over $150 or so) are 2 to 8 channels, fairly crappy/no brand and have what it seems to me a very poor interface/web server/command line (and I don't even want to mention the possible security holes) and ship for €30-€100.

And I have anyway need to find reasons/ways to learn hands on the Mikrotik scripting language.

An el-cheapo photoresistor relay module ships from Aliexpress for (less than) €2 (XH-M131), a "better" one with a delay/timer module (FC-66 or similar) for (less than) €5[1].

One of the fundamentals in using relays is to opto-isolate the command/logic from the load, I can see little better than an actual led+photoresistor as an isolator, and this allows to not open/modify the actual Mikrotik (that could be under warranty).

Of course it is just for fun and sort of half-@§§ed or MacGyverish...


[1] depending on the use the latter may be needed

I was looking for a single smallish 2.4 GHz access point, and thought that a hap lite (price new some €22+9.99 shipping) would have done nicely for my intended use, when I happened to find an e-bay offer for 4 used hap lites TC for €30 including shipping.

It goes without saying that I have now 3 unused hap lites to play with , in the worst case they can be used as "dumb" four port switch.

...

Then I thought, what if I could use one of these things as a web/ethernet relay? (yes, single channel, wired, not one of those wifi thingies)

...

And I have anyway need to find reasons/ways to learn hands on the Mikrotik scripting language.

...

Of course it is just for fun and sort of half-@§§ed or MacGyverish...

I agree on absolutely everything.

I try to be thrifty, but fail miserably at it.

Web/ethernet relays are super cool. I use them quite a bit -- Shelly has great products, integrate well (in a number of different way) with Home Assistant, and with just right level of DIY for me.

I would not be surprised if you could integrate Shelly relays directly with Mikrotik devices using MQTT, thereby eliminating the need for a separate server such as Home Assistant. And, it would indeed create a substantial need for substantial scripting skills.

Curiosity of the day (only for the record and for future memory).

After quite a few tests, it seems that a good way to (momentarily) switch off the user led and have it back on is the following (completely crazy IMHO BTW):
1) set the pwr-line1 interface to disabled (so that there is no risk whatever about it ever actually works/can be connected to)
2) set the user-led to monitor (Type) "modem signal" on interface pwr-line1 and enable it
3) the user led will switch ON

Now on terminal issue: Since the led setting is already enabled and the led is already ON, in theory nothing should happen , but in practice the led will be briefly turned OFF before being turned ON again. .