{"action":"created","issue":{"url":"https://api.github.com/repos/riptideio/pymodbus/issues/295","repository_url":"https://api.github.com/repos/riptideio/pymodbus","labels_url":"https://api.github.com/repos/riptideio/pymodbus/issues/295/labels{/name}","comments_url":"https://api.github.com/repos/riptideio/pymodbus/issues/295/comments","events_url":"https://api.github.com/repos/riptideio/pymodbus/issues/295/events","html_url":"https://github.com/riptideio/pymodbus/pull/295","id":318221694,"number":295,"title":"Fix device information selectors","user":{"login":"chintal","id":226507,"avatar_url":"https://avatars0.githubusercontent.com/u/226507?v=4","gravatar_id":"","url":"https://api.github.com/users/chintal","html_url":"https://github.com/chintal","followers_url":"https://api.github.com/users/chintal/followers","following_url":"https://api.github.com/users/chintal/following{/other_user}","gists_url":"https://api.github.com/users/chintal/gists{/gist_id}","starred_url":"https://api.github.com/users/chintal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chintal/subscriptions","organizations_url":"https://api.github.com/users/chintal/orgs","repos_url":"https://api.github.com/users/chintal/repos","events_url":"https://api.github.com/users/chintal/events{/privacy}","received_events_url":"https://api.github.com/users/chintal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-04-26T22:43:13Z","updated_at":"2018-05-02T07:44:42Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/riptideio/pymodbus/pulls/295","html_url":"https://github.com/riptideio/pymodbus/pull/295","diff_url":"https://github.com/riptideio/pymodbus/pull/295.diff","patch_url":"https://github.com/riptideio/pymodbus/pull/295.patch"},"body":"This PR corrects the Modbus Device information object_ids and category boundaries to match with the MODBUS Application Protocol Specification (V1.1b3). This change will cause changes in behavior of existing code, but make it compatible with the specification. A middle ground may be considered which eliminates the intermediate 'reserved' section, making it possible for anyone using the current pymodbus private range of 0x08-0x80 to continue to do so. \r\n\r\nIn any case, the extant implementation breaks compatibility with fully compliant Modbus clients, including pymodbus itself. These problems revealed themselves during the development of tests for PR #293, and will have to be fixed before #293 will have passing tests.\r\n\r\nThe following are the major elements of the specs the current code is in violation of : \r\n\r\n- The read device identification function provides a start object_id, which the spec recommends the client start reading at zero - though it need not be zero. In fact, all subsequent calls made necessary by long information strings and limitations of the ADU size will require non-zero values for the start object_id. It should then return all object IDs after it, stopping at the category boundary defined by the read type. \r\n- The range 0x07 - 0x7F is reserved, not private, and should ideally not be used at all.\r\n- The range 0x80 - 0xFF is private, not out of bounds, and the content is device / server dependent. In this implementation we do make the additional assumption that any object_id with an empty string is a non-existing / invalid object_id.\r\n"},"comment":{"url":"https://api.github.com/repos/riptideio/pymodbus/issues/comments/385892274","html_url":"https://github.com/riptideio/pymodbus/pull/295#issuecomment-385892274","issue_url":"https://api.github.com/repos/riptideio/pymodbus/issues/295","id":385892274,"user":{"login":"chintal","id":226507,"avatar_url":"https://avatars0.githubusercontent.com/u/226507?v=4","gravatar_id":"","url":"https://api.github.com/users/chintal","html_url":"https://github.com/chintal","followers_url":"https://api.github.com/users/chintal/followers","following_url":"https://api.github.com/users/chintal/following{/other_user}","gists_url":"https://api.github.com/users/chintal/gists{/gist_id}","starred_url":"https://api.github.com/users/chintal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chintal/subscriptions","organizations_url":"https://api.github.com/users/chintal/orgs","repos_url":"https://api.github.com/users/chintal/repos","events_url":"https://api.github.com/users/chintal/events{/privacy}","received_events_url":"https://api.github.com/users/chintal/received_events","type":"User","site_admin":false},"created_at":"2018-05-02T07:44:42Z","updated_at":"2018-05-02T07:44:42Z","author_association":"NONE","body":"@dhoomakethu I can revert the change. However, existing users of pymodbus _might_ have utilized addresses as per the pymodbus implementation. This would be contrary to the specification, but it would have more or less worked so far, as long as they have simply been using a ReadExtended based on 0x00 or a ReadSpecific command, which would not have been effected by this bug. Assuming this is acceptable, rolling back the last commit will make it fully spec-compliant, and I will do so. \r\n\r\nI was looking at the multiple request problem as well. I don't think a dedicated request is the way to go, given that there is no way for a Modbus command to be differentiated between the standard request and one that results in the need for multiple requests. The reply encoding implementation has instead been restructured in #293 to allow for truncating the response if needed. The reason I did not go all the way with it, however, was that there seemed to be no obvious way for the Response object to get information of the ADU Max Length applicable to the current request / transport. If that information is available in some way from within the response, the remaining portion is fairly trivial to implement."}}
{"actor":{"display_login":"chintal"}}