Closed corneliusmunz closed 3 years ago
If it is ok, i will try to contribute with a PR for the MoveHub. Maybe i will need some guidance 😄
I would really appreciate. Just post here when you need help!
I have done first adaptions to add the MoveHub to the project: https://github.com/corneliusmunz/powered-up/tree/feature/add_move_hub
Unfortunately if i execute the very basic example the connetion works and it fetches all ports and attached devices but after that the service receives immediately a disconnect message. I think for the Mario stuff it is the same. The disconnect is in my point of view initiated by the hub itself.
Here the trace messages i receive:
info: Example[0]
Finding Service
info: Example[0]
Press RETURN to cancel Scanning
info: SharpBrick.PoweredUp.PoweredUpHost[0]
Discovered log of type MoveHub with name 'myBoostHub' on Bluetooth Address '95892814641'
info: Example[0]
Connecting to Hub
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Connected
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Registered Receive Handler
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-00-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/0 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-01-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/1 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 09-00-04-10-02-27-00-00-01
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached Virtual IO - Port 0/16 using ports 0 + 1 of device type InternalMotorWithTacho
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-32-01-17-00-00-00-00-01-06-00-00-20
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/50 of device type RgbLight (HW: 0.1.0.0 / SW: 2.0.0.6)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3A-01-28-00-00-00-00-10-00-00-01-02
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/58 of device type InternalTilt (HW: 1.0.0.0 / SW: 0.2.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3B-01-15-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/59 of device type Current (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3C-01-14-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/60 of device type Voltage (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-46-01-42-00-01-00-00-00-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/70 of device type 66 (HW: 0.0.0.1 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-30
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillSwitchOff
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-31
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillDisconnect
Seeing your example it should all work fine. Have you tested the BT behavior when SharpBrick.PoweredUp is not involved?
Could be the same as for Mario, just that Mario would be closed even earlier.
BLE issues of MarioHub was related to a notebook and we are now deeper in the stack examining other issues. The JavaScript library implements the Lego Wireless Protocol as well and the only thing they do different between the TechnicMediumHub and the MoveHub is a firmware check on the device
Maybe you can also try it from a different notebook to rule the local computer's bluetooth stack out of the equation.
@tthiery I have merged the new changes of the master branch into my feature branch and adapted the SystemType stuff. I tried to run the example again and got the follwowing result. I think it is not realated to the notebook because the TwoPort stuff works fine:
info: Example[0]
Finding Service
info: Example[0]
Press RETURN to cancel Scanning
info: SharpBrick.PoweredUp.PoweredUpHost[0]
Discovered log of type MoveHub with name 'myBoostHub' on Bluetooth Address '95892814641'
info: Example[0]
Connecting to Hub
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Connected
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-00-01-27-00-00-00-00-10-00-00-00-10
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Registered Receive Handler
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/0 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-01-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/1 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 09-00-04-10-02-27-00-00-01
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached Virtual IO - Port 0/16 using ports 0 + 1 of device type InternalMotorWithTacho
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-32-01-17-00-00-00-00-01-06-00-00-20
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/50 of device type RgbLight (HW: 0.1.0.0 / SW: 2.0.0.6)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3A-01-28-00-00-00-00-10-00-00-01-02
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/58 of device type InternalTilt (HW: 1.0.0.0 / SW: 0.2.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3B-01-15-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/59 of device type Current (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3C-01-14-00-02-00-00-00-00-00-01-00
fail: SharpBrick.PoweredUp.Protocol.LegoWirelessProtocol[0]
Exception in LegoWirelessProtocol Decode/Knowledge
System.NotImplementedException: The method or operation is not implemented.
at SharpBrick.PoweredUp.Voltage.GetStaticPortInfoMessages(Version softwareVersion, Version hardwareVersion, SystemType systemType) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Devices\Voltage.cs:line 38
at SharpBrick.PoweredUp.Protocol.Knowledge.KnowledgeManager.AddCachePortAndPortModeInformation(DeviceType type, Version hardwareRevision, Version softwareRevision, HubInfo hub, PortInfo port, ProtocolKnowledge knowledge, IDeviceFactory deviceFactory) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Protocol\Knowledge\KnowledgeManager.cs:line 187
at SharpBrick.PoweredUp.Protocol.Knowledge.KnowledgeManager.ApplyDynamicProtocolKnowledge(LegoWirelessMessage message, ProtocolKnowledge knowledge, IDeviceFactory deviceFactory) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Protocol\Knowledge\KnowledgeManager.cs:line 129
at SharpBrick.PoweredUp.Protocol.LegoWirelessProtocol.<ConnectAsync>b__15_0(Byte[] data) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Protocol\LegoWirelessProtocol.cs:line 55
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-46-01-42-00-01-00-00-00-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/70 of device type 66 (HW: 0.0.0.1 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-30
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillSwitchOff
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-31
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillDisconnect
With that I can help. Every device has Static and non-static Port and Port Mode Information. I hardcode them to not need to query them from the devices (it would take like 20 BLE messages each time the hub initializes).
So for Voltage there is a branching because every hub has different voltage definitions. And here you run into the situation that none is defined for MoveHub Voltage device.
The content you dropped above with poweredup device dump-static-port -p
can be copy pasted into it.
@tthiery thanks for guiding me! I have added the static dump and i am one step further (or unfortunately at the same step as last week). I think the Port 70 of the Move hub with the device Id 66 is not known and i don't now what this means. I can also not find a DeviceType on @nathankellenicki library. Here are the debug infos of the ExampleMoveHubColors. I have pushed my code changes in the following branch: https://github.com/corneliusmunz/powered-up/tree/feature/add_move_hub
info: Example[0]
Finding Service
info: Example[0]
Press RETURN to cancel Scanning
info: SharpBrick.PoweredUp.PoweredUpHost[0]
Discovered log of type MoveHub with name 'myBoostHub' on Bluetooth Address '95892814641'
info: Example[0]
Connecting to Hub
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Connected
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Registered Receive Handler
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-00-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/0 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-01-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/1 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 09-00-04-10-02-27-00-00-01
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached Virtual IO - Port 0/16 using ports 0 + 1 of device type InternalMotorWithTacho
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-32-01-17-00-00-00-00-01-06-00-00-20
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/50 of device type RgbLight (HW: 0.1.0.0 / SW: 2.0.0.6)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3A-01-28-00-00-00-00-10-00-00-01-02
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/58 of device type InternalTilt (HW: 1.0.0.0 / SW: 0.2.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3B-01-15-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/59 of device type Current (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3C-01-14-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/60 of device type Voltage (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-46-01-42-00-01-00-00-00-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/70 of device type 66 (HW: 0.0.0.1 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-30
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillSwitchOff
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-31
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillDisconnect
Well, in case you do not understand the port or the mode, do not expose it. Remove the known port from the MoveHub implementation (maybe comment it out). I guess, like that the library will not try to await it announcement as AttachedHubIO message and the initialization can complete.
If you comment it out and leave it like that, create an issue for investigation. I also have little hesitation filing issues against the documentation repo of Lego.
btw, I would not be surprised if this is a Debug port like exposed on the MarioHub.
Ok, i have commented it out in the MoveHub.cs but now i receive the following error. So sorry for bothering you all the time...
info: Example[0]
Finding Service
info: Example[0]
Press RETURN to cancel Scanning
info: SharpBrick.PoweredUp.PoweredUpHost[0]
Discovered log of type MoveHub with name 'myBoostHub' on Bluetooth Address '95892814641'
info: Example[0]
Connecting to Hub
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Connected
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
Registered Receive Handler
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-00-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/0 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-01-01-27-00-00-00-00-10-00-00-00-10
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/1 of device type InternalMotorWithTacho (HW: 1.0.0.0 / SW: 1.0.0.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 09-00-04-10-02-27-00-00-01
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached Virtual IO - Port 0/16 using ports 0 + 1 of device type InternalMotorWithTacho
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-32-01-17-00-00-00-00-01-06-00-00-20
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/50 of device type RgbLight (HW: 0.1.0.0 / SW: 2.0.0.6)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3A-01-28-00-00-00-00-10-00-00-01-02
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/58 of device type InternalTilt (HW: 1.0.0.0 / SW: 0.2.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3B-01-15-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/59 of device type Current (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-3C-01-14-00-02-00-00-00-00-00-01-00
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Attached IO - Port 0/60 of device type Voltage (HW: 0.0.0.2 / SW: 0.0.1.0)
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 0F-00-04-46-01-42-00-01-00-00-00-00-00-00-10
fail: SharpBrick.PoweredUp.Protocol.LegoWirelessProtocol[0]
Exception in LegoWirelessProtocol Decode/Knowledge
System.NullReferenceException: Object reference not set to an instance of an object.
at SharpBrick.PoweredUp.Hub.OnHubAttachedIOMessage(HubAttachedIOMessage hubAttachedIO) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Hubs\Hub_Ports.cs:line 117
at SharpBrick.PoweredUp.Hub.OnHubChange(LegoWirelessMessage message) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Hubs\Hub.cs:line 102
at System.Reactive.AnonymousSafeObserver`1.OnNext(T value) in /_/Rx.NET/Source/src/System.Reactive/AnonymousSafeObserver.cs:line 43
at System.Reactive.Sink`1.ForwardOnNext(TTarget value) in /_/Rx.NET/Source/src/System.Reactive/Internal/Sink.cs:line 49
at System.Reactive.Linq.ObservableImpl.Where`1.Predicate._.OnNext(TSource value) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/Where.cs:line 54
at System.Reactive.Sink`1.ForwardOnNext(TTarget value) in /_/Rx.NET/Source/src/System.Reactive/Internal/Sink.cs:line 49
at System.Reactive.Linq.ObservableImpl.Select`2.Selector._.OnNext(TSource value) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/Select.cs:line 47
at System.Reactive.Subjects.Subject`1.OnNext(T value) in /_/Rx.NET/Source/src/System.Reactive/Subjects/Subject.cs:line 146
at SharpBrick.PoweredUp.Protocol.LegoWirelessProtocol.<ConnectAsync>b__15_0(Byte[] data) in C:\Users\Cornelius\source\repos\powered-up-fork\src\SharpBrick.PoweredUp\Protocol\LegoWirelessProtocol.cs:line 57
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-30
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillSwitchOff
dbug: SharpBrick.PoweredUp.Bluetooth.BluetoothKernel[0]
< 04-00-02-31
info: SharpBrick.PoweredUp.Functions.TraceMessages[0]
Hub Action - HubWillDisconnect
That you have to debug. Probably the library has a bug because it never saw an unknown port 🤣
Sorry. Too Late to deep dive
Hi guys, I started playing around with getting my R2D2 to move using this library (which is awesome btw) and it's MoveHub using the branch done by corneliusmunz.
With the above issue, I found that leaving the port 70 in was the best option since the port gets announced by cannot find it in OnHubAttachedIOMessage (needs a null check in here to handle that scenario).
With the MoveHub connection, what I found was since the code to handle virtual ports (case OnHubAttachedIOMessage) is commented out in the switch statement, it's waiting for that virtual port (AB) to be attached in ExpectedDevicesCompletedAsync. I'm not sure why the code is commented out but once I un-commented it it worked fine and was able to start accessing the internal motor and external motor with some added code into the MoveHub.
Main question is if a good reason that code was commented out or not?
One thing I noticed with the MoveHub is that it has a very short timeout when you first turn it on, so if you don't finish connecting very quickly it will turn itself off.
Reason for commenting out: the active use case (CreateVirtualPort) is handled here vs the general handler. I think the handler was raised twice when creating the VP manually.
Solution is likely to modify the logic during the expected device phase.
Would anyone with the hardware mind finishing up this merge request 😁. @corneliusmunz is a bit busy with the legoino project so I think he does not mind when someone else finished it.
@KeyDecoder would be great if you take over the work which i have done. I can do some testing on a real device if this is needed. I also have experienced that the MoveHub needs very short connection times compared to all other hubs i have tested.
Sure, I can take a look although looks like you've pretty much done most of it.
For the virtual port, I'm assuming it was an issue where you told a device to create a virtual port and it then notified you, triggering the same code path twice?
If that is the case, what if we add a check when processing the attached virtual IO message to see if device already attached in the port (and the port exists as well) and if so then either ignore the message or detach and create a new device.
If we don't expect any more notifications after the connect, we could also just disable the handling of that message if received from the hub (which matches the logic that exists right now).
The Lego Wireless Protocol for most parts is a request-response protocol. In the CreateVirtualPortAsync method we have to await the response. I would suggest that we introduce a boolean flag during the expected device discovery period to allow the general HubAttachedIO handler (uni-directional messages btw) to process the event (the uncommented code). After the expected device block we lock the behavior again. A bit ugly because it is state but it is within the hub logic part so I am fine with it.
Added PR. I've tried to keep the code styling consistent. Apologies if done anything the wrong way.
I handling the virtual port so during connection it will handle notifications from attaching virtual ports but after that it ignores them. That allows the MoveHub to register its virtual ports but maintains the current behaviour for manually creating virtual ports from the applications. Since I don't have any hardware to test virtual ports, this seemed best. I don't think this is exactly what you meant but it would be hard to implement that without any hardware test that with.
Add support for the MoveHub (88006) which is used in the Boost and StarWars Sets. Attached you will find the needed CLI Logs
Port 0
Port 1
Port 16
Port 50
Port 58
Port 59
Port 60
Port 70