So far transition accept actions seem to work as triggers only; any attempt to actually consume even a simple real r:Real value (from an attribute feature of payload) in a following effect action do statement either causes a payload drop or a "hang". Similarly, trying to use the received r:Real payload in an if guard fails.
PARTIAL WORKAROUND: If you have two parts (lets call them tx and rx) with ports (say tx.o and rx.i) with a port type with a primitive directed attribute r:Real, you can simply set tx.o.r using an assign and it will be "received" and can be read as rx.i.r. You don't need a binding connector between the port features for this to work, an interface between the ports suffices.
However, just setting tx.o.r does not act as a trigger. You therefore have to at the tx end both assign the port value AND then immediately also send via the port; you can then listen for the "change" using an accept for a new payload as trigger via the port rx.i and then "poll" it as rx.i.r to fetch the latest value and consume it (assign or otherwise use). Clean timing is however not guaranteed.