<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Small bugs found in the Dimming server example</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/77277/small-bugs-found-in-the-dimming-server-example</link><description>The first bug : I believe that the target level argument for the definition of the transition callback should be of type int16_t instead of the unsigned version since it is inconsistent with the get and set callbacks. Also iirc according to the generic</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 13 Jul 2021 06:09:49 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/77277/small-bugs-found-in-the-dimming-server-example" /><item><title>RE: Small bugs found in the Dimming server example</title><link>https://devzone.nordicsemi.com/thread/319698?ContentTypeID=1</link><pubDate>Tue, 13 Jul 2021 06:09:49 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:efe5789b-a199-435b-b26f-5fbfba88a392</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Yes, you are right, generic level should be a signed value. According to the Mesh Model specification v. 1.0.1, section 3.1.2 Generic Level: &amp;quot;The Generic Level state is a 16-bit signed integer (2&amp;#39;s complement) representing the state of an element.&amp;quot;&lt;/p&gt;
&lt;p&gt;Definitely a bug. Thanks!&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Small bugs found in the Dimming server example</title><link>https://devzone.nordicsemi.com/thread/319678?ContentTypeID=1</link><pubDate>Mon, 12 Jul 2021 18:37:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:acab0e91-7c47-4faf-a238-16d8ade091b3</guid><dc:creator>Jeffe</dc:creator><description>&lt;p&gt;I can&amp;#39;t see how the level is ever supposed to be an unsigned value because the delta level, like the set level and move level, is also represented by a signed type (int32_t to be specific). The generic level model seems to define all the level values as a signed integer&lt;/p&gt;
&lt;p&gt;To clarify what I find odd, here is a picture of the output (no fixes, just the original dimming examples)&lt;/p&gt;
&lt;p&gt;&lt;img alt=" " src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/communityserver-discussions-components-files/4/Screenshot-from-2021_2D00_07_2D00_12-11_2D00_26_2D00_45.png" /&gt;&lt;/p&gt;
&lt;p&gt;The top rtt output is the client and the bottom rtt output is the server&lt;/p&gt;
&lt;p&gt;You can see that the set command in the client side is the target level is the correct signed type but in the server output it is the unsigned version. For example, in the last input from the client where it sets the target level from -20000 to -30000, on the server side it outputs the target level as 35536. I think its clear that its a mistake due to the uint16_t argument from the transition callback casting a signed int16_t input as its argument to a uint16. In this case it turns -30000 to 35536, but those two numbers exact same representation in binary which is indicative of a signed -&amp;gt; unsigned casting.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Small bugs found in the Dimming server example</title><link>https://devzone.nordicsemi.com/thread/319673?ContentTypeID=1</link><pubDate>Mon, 12 Jul 2021 17:43:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:39987a1e-9079-4150-ab2c-5cc3efbb3217</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Thank you for the reports, it is highly appreciated!&lt;/p&gt;
&lt;p&gt;The first issue might be a bug, yes. I have reported it through our internal issue tracker. I agree the inconsistency looks out of place. Please note, however, that while the callbacks for set and get are used also for deltas (meaning both positive and negative values might apply), the transition target_level is an absolute value. Are you sure the level itself is not actually supposed to be an unsigned value?&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Small bugs found in the Dimming server example</title><link>https://devzone.nordicsemi.com/thread/319440?ContentTypeID=1</link><pubDate>Fri, 09 Jul 2021 16:43:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5f6bdb36-bfe1-4b80-923f-37e5d9b50850</guid><dc:creator>Jeffe</dc:creator><description>&lt;p&gt;Update: THe second bug is not actually a bug, its just that i was dumb and forgot to set publishing for the server and subscribing for the client (the other way). I have crossed it out in the main post&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>