Development

[Icesory]

Expand function in helper.coffee

[sweetpi]

Very nice. Could you change one thing?

I don't want the dimmer protocol to convert the dimlevel from the range to percentage and vise versa. I think the conversion should be done in pimatic-homeduino. So could you move the conversion from the rfcontroljs protocol to the Dimmer Device (https://github.com/pimatic/pimatic-homeduino/pull/4).

For this purpose please add the min, max value to the protocolInfo.values.dimlevel object.

[Icesory]

Ok. this is a realy good idea. But some strange thing still left with dimmer. Sorry to complex for to tell it in english Wenn man den Dimmer mit Pimatic steuert hat man nur die Möglichkeit ihn über das level einzuschalten. Normal kann man die Dimmer aber ein und ausschalten und sie haben sich ihr altes dimmlevel gespeichert. Also ich stelle den Dimmer auf 65%. Mit einem DummySwitch steuer ich den State des Dimmers und setze ihn auf off. Die lampe geht aus. Dabei sollte aber nicht das Dimlevel 0 gesendet werden. Schalte ich mit dem Dummy den state wieder auf on dann soll der Dimmer wieder auf 65% gehen. Daran habe ich schon gearbeitet hatte aber probleme mit Timeouts.

[sweetpi]

But some strange thing still left with dimmer. Sorry to complex for to tell it in english Wenn man den Dimmer mit Pimatic steuert hat man nur die Möglichkeit ihn über das level einzuschalten. Normal kann man die Dimmer aber ein und ausschalten und sie haben sich ihr altes dimmlevel gespeichert. Also ich stelle den Dimmer auf 65%. Mit einem DummySwitch steuer ich den State des Dimmers und setze ihn auf off. Die lampe geht aus. Dabei sollte aber nicht das Dimlevel 0 gesendet werden. Schalte ich mit dem Dummy den state wieder auf on dann soll der Dimmer wieder auf 65% gehen. Daran habe ich schon gearbeitet hatte aber probleme mit Timeouts.

I never had a dimmer, so I didn't know this. For me it was "dimlevel = 0" is "off". I think about changing the behavior.

[Icesory]

I think i get this working. I have a other problem and ned a hint to solve this. https://github.com/Icesory/pimatic-homeduino/commit/a94d98ba9c42b02c8c8cd88f7e82f7e66866ca93 I have designed a universal Sensor. But i would have an entry in the config to define the order of the values. for that the if has... functions must be in a map or an array to get them by name or number.

[Icesory]

There it is https://github.com/Icesory/pimatic-homeduino/commit/02fd0d3c6d3b50a8c4a54a2933310db124a8dabb https://github.com/Icesory/rfcontroljs/commit/e20a959b28c6e8803e1a6288211597d81b3fcb87

[sweetpi]

Whats the reason for changing the binaryToNumber function? If we are doing two different things related to the last argument, we could just write two different functions, or? What was wrong with binaryToNumberRevert, the (confusing) name?

[Icesory]

Yes it was only the name. The statement LSB-MSB and MSB-LSB is more clear. I my mind :)

[sweetpi]

Yes it was only the name. The statement LSB-MSB and MSB-LSB is more clear. I my mind :)

You are right. I wasn't so creative :) Changed it a little bit to get rid of the additional parameter.

[Icesory]

Ok. But now you have removed an speciall function. Lets say a data telegram has at position 1 the signedbit and from 10 to 18 the data. Now we cant acces the signedbit right. binaryToNumberSigned: (data, b, e, direction = 'MSB-LSB', signedPos = null) With this function we can access a signedbit which isnt at the end or the start of the data if the signedPos dont set it used the MSB or LSB for the signedbit.

[sweetpi]

Lets say a data telegram has at position 1 the signedbit and from 10 to 18 the data. Now we cant acces the signedbit right.

I can't imagine that someone does invent such strange protocol/encoding :D

[Icesory]

You are right. At the moment it isnt necessary. But eventually in future. And than i will add it again :) Thank you for your help.